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
535de7ec1fee94eae1769630b512c6ef4eb5bcad
blender-archive/source/blender/render/intern/source/render_texture.c

3786 lines
110 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
/*
* ***** 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,
correct fsf address
2010-02-12 13:34:04 +00:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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 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
*/
doxygen: blender/render tagged.
2011-02-27 19:31:27 +00:00
/** \file blender/render/intern/source/render_texture.c
* \ingroup render
*/
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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>
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
#include "BLI_math.h"
remove BLI_noise from BLI_blenlib.h, not that many files need this.
2012-10-12 00:18:32 +00:00
#include "BLI_noise.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 "BLI_rand.h"
split BKE_utildefines.h, now it only has blender specific defines like GS() MAKE_ID, FILE_MAXDIR, moved the generic defines to BLI_utildefines.h. no functional changes.
2011-01-07 18:36:47 +00:00
#include "BLI_utildefines.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
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
#include "DNA_anim_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_texture_types.h"
#include "DNA_object_types.h"
#include "DNA_lamp_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"
Color Management, Stage 2: Switch color pipeline to use OpenColorIO Replace old color pipeline which was supporting linear/sRGB color spaces only with OpenColorIO-based pipeline. This introduces two configurable color spaces: - Input color space for images and movie clips. This space is used to convert images/movies from color space in which file is saved to Blender's linear space (for float images, byte images are not internally converted, only input space is stored for such images and used later). This setting could be found in image/clip data block settings. - Display color space which defines space in which particular display is working. This settings could be found in scene's Color Management panel. When render result is being displayed on the screen, apart from converting image to display space, some additional conversions could happen. This conversions are: - View, which defines tone curve applying before display transformation. These are different ways to view the image on the same display device. For example it could be used to emulate film view on sRGB display. - Exposure affects on image exposure before tone map is applied. - Gamma is post-display gamma correction, could be used to match particular display gamma. - RGB curves are user-defined curves which are applying before display transformation, could be used for different purposes. All this settings by default are only applying on render result and does not affect on other images. If some particular image needs to be affected by this transformation, "View as Render" setting of image data block should be set to truth. Movie clips are always affected by all display transformations. This commit also introduces configurable color space in which sequencer is working. This setting could be found in scene's Color Management panel and it should be used if such stuff as grading needs to be done in color space different from sRGB (i.e. when Film view on sRGB display is use, using VD16 space as sequencer's internal space would make grading working in space which is close to the space using for display). Some technical notes: - Image buffer's float buffer is now always in linear space, even if it was created from 16bit byte images. - Space of byte buffer is stored in image buffer's rect_colorspace property. - Profile of image buffer was removed since it's not longer meaningful. - OpenGL and GLSL is supposed to always work in sRGB space. It is possible to support other spaces, but it's quite large project which isn't so much important. - Legacy Color Management option disabled is emulated by using None display. It could have some regressions, but there's no clear way to avoid them. - If OpenColorIO is disabled on build time, it should make blender behaving in the same way as previous release with color management enabled. More details could be found at this page (more details would be added soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management -- Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO integration and to Brecht van Lommel for some further development and code/ usecase review!
2012-09-15 10:05:07 +00:00
#include "IMB_colormanagement.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
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"
remove references to BKE_utildefines where its not needed. - move GS() define into DNA_ID.h - add BLI_utildefines as an automatic include with makesrna generated files.
2011-01-07 19:18:31 +00:00
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
#include "BKE_animsys.h"
#include "BKE_DerivedMesh.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_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"
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
#include "BKE_scene.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_texture.h"
Dynamic Paint: * Fixed a memory leak from previous commit.
2011-10-22 17:15:32 +00:00
#include "MEM_guardedalloc.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 "render_types.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"
Ocean Sim modifier patch by Matt Ebb, Hamed Zaghaghi This adds a new Modifier "Ocean" to simulate large-scale wave motion. Details can be found in the wiki documentation [1], the project homepage [2] and the patch tracker [3] The modifier is disabled by default for now. To enable it, the WITH_OCEANSIM (cmake) / WITH_BF_OCEANSIM (scons) flags have to be set. The code depends on fftw3, so this also has to be enabled. [1] http://wiki.blender.org/index.php/Doc:2.6/Manual/Modifiers/Simulation/Ocean [2] http://www.savetheoceansim.com [3] http://projects.blender.org/tracker/?group_id=9&atid=127&func=detail&aid=28338
2011-11-13 12:17:27 +00:00
#include "texture_ocean.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 */
quiet -Wmissing-prototypes warnings, and enable this warning by default for C with gcc. helps for finding unused functions and making functions static, also did some minor code cleanup.
2012-09-15 01:52:28 +00:00
#include "RE_render_ext.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
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */
/* 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;
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */
Fix T42139, vertical noise stripe patterns in noise texture. Two fixes here (only the second one is strictly needed to fix the issue, but both make the system better). First is introduction of a random generator array for use with threaded systems where each thread needs to access its own number generator. The random texture now uses this so it should not be influenced by other random generator reseedings of the main random generator like it did before. Second, I reshuffled the texture code to resample the upper bits of the random number first. According to Numerical Recipes, this is where the most variance can be found, so by sampling those we avoid correlation issues. Also, multiplying here is not ideal because if a pair of bits are zero, then the whole result will also be zero. Overall this is much more random (tm) than before, however result will also be brighter, since we now have less black spots. Tweaking the brightness/contrast should somewhat fix that, generally having the same result as before is not possible anyway if we are to really fix this. Also, seems like exposing procedural depth might be nice here since it influences the precision of the texture lookup.
2014-10-09 15:48:38 +02:00
static RNG_THREAD_ARRAY *random_tex_array;
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
Minor cleanup. * Use pie direction, not draw type for pie item collision * Strict function definitions. * Initialize random array with system time
2014-10-09 17:12:32 +02:00
void RE_init_texture_rng(void)
Fix T42139, vertical noise stripe patterns in noise texture. Two fixes here (only the second one is strictly needed to fix the issue, but both make the system better). First is introduction of a random generator array for use with threaded systems where each thread needs to access its own number generator. The random texture now uses this so it should not be influenced by other random generator reseedings of the main random generator like it did before. Second, I reshuffled the texture code to resample the upper bits of the random number first. According to Numerical Recipes, this is where the most variance can be found, so by sampling those we avoid correlation issues. Also, multiplying here is not ideal because if a pair of bits are zero, then the whole result will also be zero. Overall this is much more random (tm) than before, however result will also be brighter, since we now have less black spots. Tweaking the brightness/contrast should somewhat fix that, generally having the same result as before is not possible anyway if we are to really fix this. Also, seems like exposing procedural depth might be nice here since it influences the precision of the texture lookup.
2014-10-09 15:48:38 +02:00
{
random_tex_array = BLI_rng_threaded_new();
}
Minor cleanup. * Use pie direction, not draw type for pie item collision * Strict function definitions. * Initialize random array with system time
2014-10-09 17:12:32 +02:00
void RE_exit_texture_rng(void)
Fix T42139, vertical noise stripe patterns in noise texture. Two fixes here (only the second one is strictly needed to fix the issue, but both make the system better). First is introduction of a random generator array for use with threaded systems where each thread needs to access its own number generator. The random texture now uses this so it should not be influenced by other random generator reseedings of the main random generator like it did before. Second, I reshuffled the texture code to resample the upper bits of the random number first. According to Numerical Recipes, this is where the most variance can be found, so by sampling those we avoid correlation issues. Also, multiplying here is not ideal because if a pair of bits are zero, then the whole result will also be zero. Overall this is much more random (tm) than before, however result will also be brighter, since we now have less black spots. Tweaking the brightness/contrast should somewhat fix that, generally having the same result as before is not possible anyway if we are to really fix this. Also, seems like exposing procedural depth might be nice here since it influences the precision of the texture lookup.
2014-10-09 15:48:38 +02:00
{
BLI_rng_threaded_free(random_tex_array);
}
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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 warnings from Sparse static source code checker, mostly BKE/BLI and python functions. - use NULL rather then 0 where possible (makes code & function calls more readable IMHO). - set static variables and functions (exposed some unused vars/funcs). - use func(void) rather then func() for definitions.
2011-02-13 10:52:18 +00:00
static 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
{
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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 */
Code Cleanup: replace checks for ima->source with BKE_image_is_animated
2014-01-14 04:59:58 +11:00
if (tex->ima && BKE_image_is_animated(tex->ima)) {
fix for missing NULL check in init_render_texture() (possibly own fault), also remove some redundant code.
2012-09-19 08:09:22 +00:00
BKE_image_user_frame_calc(&tex->iuser, re ? re->r.cfra : 0, 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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (tex->type==TEX_ENVMAP) {
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have to do it themselves. This commit will need quite some testing help, but I'm around!
2003-12-21 21:52:51 +00:00
/* 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;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->env) {
if (tex->env->type==ENV_PLANE)
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
tex->extend= TEX_EXTEND;
/* only free envmap when rendermode was set to render envmaps, for previewrender */
code cleanup: rename G.afbreek --> is_break, G.rendering --> is_rendering
2012-08-08 18:37:06 +00:00
if (G.is_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)
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->env->stype==ENV_ANIM)
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
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->nodetree && tex->use_nodes) {
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
ntreeTexBeginExecTree(tex->nodetree); /* has internal flag to detect it only does it once */
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
}
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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;
2.5: code changes to reduce the usage of G.main and pass it along or get it from the context instead.
2010-08-01 12:47:49 +00:00
tex= re->main->tex.first;
style cleanup: follow style guide for/with/if spacing
2012-03-24 07:52:14 +00:00
while (tex) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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;
}
}
fix for warnings from Sparse static source code checker, mostly BKE/BLI and python functions. - use NULL rather then 0 where possible (makes code & function calls more readable IMHO). - set static variables and functions (exposed some unused vars/funcs). - use func(void) rather then func() for definitions.
2011-02-13 10:52:18 +00:00
static void end_render_texture(Tex *tex)
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
{
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex && tex->use_nodes && tex->nodetree && tex->nodetree->execdata)
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
ntreeTexEndExecTree(tex->nodetree->execdata);
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
}
2.5: code changes to reduce the usage of G.main and pass it along or get it from the context instead.
2010-08-01 12:47:49 +00:00
void end_render_textures(Render *re)
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
{
Tex *tex;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
for (tex= re->main->tex.first; tex; tex= tex->id.next)
if (tex->id.us)
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
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]);
Divide by 3 instead of multiplying by variations of 0.333 Fixes small precision problems.
2013-02-14 17:35:43 +00:00
texres->nor[0]= (fac0 - fac1) / 3.0f;
texres->nor[1]= (fac0 - fac2) / 3.0f;
texres->nor[2]= (fac0 - fac3) / 3.0f;
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
}
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
static int blend(Tex *tex, const float texvec[3], 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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->flag & TEX_FLIPBLEND) {
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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= 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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->stype==TEX_LIN) { /* lin */
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
texres->tin= (1.0f+x)/2.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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (tex->stype==TEX_QUAD) { /* quad */
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
texres->tin= (1.0f+x)/2.0f;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (texres->tin<0.0f) texres->tin= 0.0f;
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->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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (tex->stype==TEX_EASE) { /* ease */
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
texres->tin= (1.0f+x)/2.0f;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (texres->tin<=0.0f) texres->tin= 0.0f;
else if (texres->tin>=1.0f) texres->tin= 1.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
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;
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
texres->tin= (3.0f*t-2.0f*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
}
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (tex->stype==TEX_DIAG) { /* diag */
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
texres->tin= (2.0f+x+y)/4.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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (tex->stype==TEX_RAD) { /* radial */
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
texres->tin = (atan2f(y, x) / (2 * M_PI) + 0.5f);
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 { /* sphere TEX_SPHERE */
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
texres->tin = 1.0 - sqrtf(x * x + y * y + texvec[2] * texvec[2]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (texres->tin<0.0f) texres->tin= 0.0f;
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 */
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
static int clouds(Tex *tex, const float texvec[3], 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) {
style cleanup
2012-07-07 22:51:57 +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) {
style cleanup
2012-07-07 22:51:57 +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)
{
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
a = 0.5 + 0.5 * sinf(a);
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
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;
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
a = rmax - 2.0f*fabsf(floorf((a*(1.0f/b))+0.5f) - (a*(1.0f/b)));
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
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)
{
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
float wi = 0;
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 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) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
wi = waveform[wf]((x + y + z)*10.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
}
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) {
quiet -Wdouble-promotion warnings
2011-11-11 12:00:08 +00:00
wi = waveform[wf](sqrtf(x*x + y*y + z*z)*20.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
}
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);
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
wi = waveform[wf]((x + y + z)*10.0f + wi);
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_RINGNOISE) {
wi = tex->turbul*BLI_gNoise(tex->noisesize, x, y, z, (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
quiet -Wdouble-promotion warnings
2011-11-11 12:00:08 +00:00
wi = waveform[wf](sqrtf(x*x + y*y + z*z)*20.0f + wi);
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
}
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
}
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
static int wood(Tex *tex, const float texvec[3], 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 */
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
n = 5.0f * (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) {
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
mi = sqrtf(mi);
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +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 (mt==TEX_SHARPER) {
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
mi = sqrtf(sqrtf(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
}
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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;
}
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
static int marble(Tex *tex, const float texvec[3], 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
}
/* ------------------------------------------------------------------------- */
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
static int magic(Tex *tex, const float texvec[3], 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 for bad NULL check in bmo_connect_pair, also remove duplicate checks in if statements and redundant initialization vars.
2013-07-13 16:25:47 +00:00
float x, y, z, 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
int n;
n= tex->noisedepth;
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
turb= tex->turbul/5.0f;
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
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
x = sinf(( texvec[0] + texvec[1] + texvec[2]) * 5.0f);
y = cosf((-texvec[0] + texvec[1] - texvec[2]) * 5.0f);
z = -cosf((-texvec[0] - texvec[1] + texvec[2]) * 5.0f);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
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;
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
y= -cosf(x-y+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
y*= turb;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (n>1) {
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
x= cosf(x-y-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
x*= turb;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (n>2) {
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
z= sinf(-x-y-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
z*= turb;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (n>3) {
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
x= -cosf(-x+y-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
x*= turb;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (n>4) {
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
y= -sinf(-x+y+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
y*= turb;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (n>5) {
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
y= -cosf(-x+y+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
y*= turb;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (n>6) {
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
x= cosf(x+y+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
x*= turb;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (n>7) {
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
z= sinf(x+y-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
z*= turb;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (n>8) {
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
x= -cosf(-x-y+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
x*= turb;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (n>9) {
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
y= -sinf(x-y+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
y*= turb;
}
}
}
}
}
}
}
}
}
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (turb!=0.0f) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
turb*= 2.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
x/= turb;
y/= turb;
z/= turb;
}
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
texres->tr = 0.5f - x;
texres->tg = 0.5f - y;
texres->tb = 0.5f - 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
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
texres->tin= (1.0f / 3.0f) * (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;
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
texres->ta = 1.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
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 */
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
static int stucci(Tex *tex, const float texvec[3], 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
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
ofs= tex->turbul/200.0f;
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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);
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
nor[1] = BLI_gNoise(tex->noisesize, texvec[0], texvec[1]+ofs, texvec[2], (tex->noisetype!=TEX_NOISESOFT), tex->noisebasis);
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[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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (texres->nor) {
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
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(texres->nor, nor);
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
tex_normal_derivate(tex, texres);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (texres->tin<0.0f)
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= 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 */
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
static float mg_mFractalOrfBmTex(Tex *tex, const float texvec[3], 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) {
style cleanup
2012-07-07 22:51:57 +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;
}
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
static float mg_ridgedOrHybridMFTex(Tex *tex, const float texvec[3], 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) {
style cleanup
2012-07-07 22:51:57 +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;
}
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
static float mg_HTerrainTex(Tex *tex, const float texvec[3], 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) {
style cleanup
2012-07-07 22:51:57 +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;
}
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
static float mg_distNoiseTex(Tex *tex, const float texvec[3], 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) {
style cleanup
2012-07-07 22:51:57 +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 */
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
static float voronoiTex(Tex *tex, const float texvec[3], 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;
style cleanup: spelling. also remove large, duplicate comments from sunsky.h
2012-03-09 00:41:09 +00:00
float da[4], pa[12]; /* distance and point coordinate arrays of 4 nearest neighbors */
Code cleanup: correct abs use also minor cleanup to rotation code
2014-04-21 01:54:52 +10:00
float aw1 = fabsf(tex->vn_w1);
float aw2 = fabsf(tex->vn_w2);
float aw3 = fabsf(tex->vn_w3);
float aw4 = fabsf(tex->vn_w4);
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 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);
quiet -Wdouble-promotion warnings
2011-11-11 12:00:08 +00:00
texres->tin = sc * fabsf(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) {
style cleanup
2012-07-07 22:51:57 +00:00
float offs= tex->nabla/tex->noisesize; /* also scaling of texvec */
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
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);
quiet -Wdouble-promotion warnings
2011-11-11 12:00:08 +00:00
texres->nor[0] = sc * fabsf(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);
quiet -Wdouble-promotion warnings
2011-11-11 12:00:08 +00:00
texres->nor[1] = sc * fabsf(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);
quiet -Wdouble-promotion warnings
2011-11-11 12:00:08 +00:00
texres->nor[2] = sc * fabsf(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
/* ------------------------------------------------------------------------- */
Fix T42139, vertical noise stripe patterns in noise texture. Two fixes here (only the second one is strictly needed to fix the issue, but both make the system better). First is introduction of a random generator array for use with threaded systems where each thread needs to access its own number generator. The random texture now uses this so it should not be influenced by other random generator reseedings of the main random generator like it did before. Second, I reshuffled the texture code to resample the upper bits of the random number first. According to Numerical Recipes, this is where the most variance can be found, so by sampling those we avoid correlation issues. Also, multiplying here is not ideal because if a pair of bits are zero, then the whole result will also be zero. Overall this is much more random (tm) than before, however result will also be brighter, since we now have less black spots. Tweaking the brightness/contrast should somewhat fix that, generally having the same result as before is not possible anyway if we are to really fix this. Also, seems like exposing procedural depth might be nice here since it influences the precision of the texture lookup.
2014-10-09 15:48:38 +02:00
static int texnoise(Tex *tex, TexResult *texres, int 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
{
float div=3.0;
Better fix for T42139 Noise function's significant bits are up to 31st bit. This should now give the same visual result as before, minus the stripes. Issue pointed out by Anthony Edlin, thanks!
2014-10-15 11:04:41 +02:00
int val, ran, loop, shift = 29;
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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 T42139, vertical noise stripe patterns in noise texture. Two fixes here (only the second one is strictly needed to fix the issue, but both make the system better). First is introduction of a random generator array for use with threaded systems where each thread needs to access its own number generator. The random texture now uses this so it should not be influenced by other random generator reseedings of the main random generator like it did before. Second, I reshuffled the texture code to resample the upper bits of the random number first. According to Numerical Recipes, this is where the most variance can be found, so by sampling those we avoid correlation issues. Also, multiplying here is not ideal because if a pair of bits are zero, then the whole result will also be zero. Overall this is much more random (tm) than before, however result will also be brighter, since we now have less black spots. Tweaking the brightness/contrast should somewhat fix that, generally having the same result as before is not possible anyway if we are to really fix this. Also, seems like exposing procedural depth might be nice here since it influences the precision of the texture lookup.
2014-10-09 15:48:38 +02:00
ran= BLI_rng_thread_rand(random_tex_array, 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
loop= tex->noisedepth;
Fix T42139, vertical noise stripe patterns in noise texture. Two fixes here (only the second one is strictly needed to fix the issue, but both make the system better). First is introduction of a random generator array for use with threaded systems where each thread needs to access its own number generator. The random texture now uses this so it should not be influenced by other random generator reseedings of the main random generator like it did before. Second, I reshuffled the texture code to resample the upper bits of the random number first. According to Numerical Recipes, this is where the most variance can be found, so by sampling those we avoid correlation issues. Also, multiplying here is not ideal because if a pair of bits are zero, then the whole result will also be zero. Overall this is much more random (tm) than before, however result will also be brighter, since we now have less black spots. Tweaking the brightness/contrast should somewhat fix that, generally having the same result as before is not possible anyway if we are to really fix this. Also, seems like exposing procedural depth might be nice here since it influences the precision of the texture lookup.
2014-10-09 15:48:38 +02:00
/* start from top bits since they have more variance */
val= ((ran >> shift) & 3);
style cleanup: follow style guide for/with/if spacing
2012-03-24 07:52:14 +00:00
while (loop--) {
Classic blenderplayer fix + small optimization
2014-10-09 16:05:00 +02:00
shift -= 2;
Better fix for T42139 Noise function's significant bits are up to 31st bit. This should now give the same visual result as before, minus the stripes. Issue pointed out by Anthony Edlin, thanks!
2014-10-15 11:04:41 +02:00
val *= ((ran >> shift) & 3);
div *= 3.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
}
fix for some pedantic warnings.
2010-12-03 01:52:28 +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
}
/* ------------------------------------------------------------------------- */
code cleanup: use array size and const for vector args
2012-05-26 16:04:31 +00:00
static int cubemap_glob(const float n[3], 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;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (n==NULL) {
style cleanup
2012-07-07 22:51:57 +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 {
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(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
}
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
mul_mat3_m4_v3(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
Code cleanup: correct abs use also minor cleanup to rotation code
2014-04-21 01:54:52 +10:00
x1 = fabsf(nor[0]);
y1 = fabsf(nor[1]);
z1 = fabsf(nor[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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (z1>=x1 && z1>=y1) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
*adr1 = (x + 1.0f) / 2.0f;
*adr2 = (y + 1.0f) / 2.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
ret= 0;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (y1>=x1 && y1>=z1) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
*adr1 = (x + 1.0f) / 2.0f;
*adr2 = (z + 1.0f) / 2.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
ret= 1;
}
else {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
*adr1 = (y + 1.0f) / 2.0f;
*adr2 = (z + 1.0f) / 2.0f;
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
ret= 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
}
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 */
code cleanup: use array size and const for vector args
2012-05-26 16:04:31 +00:00
static int cubemap(MTex *mtex, VlakRen *vlr, const float n[3], 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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
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];
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
normal_tri_v3(nor, vlr->v1->orco, vlr->v2->orco, vlr->v3->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
use fabsf when using floats.
2012-07-21 15:27:40 +00:00
if (fabsf(nor[0]) < fabsf(nor[2]) && fabsf(nor[1]) < fabsf(nor[2])) vlr->puno |= ME_PROJXY;
else if (fabsf(nor[0]) < fabsf(nor[1]) && fabsf(nor[2]) < fabsf(nor[1])) vlr->puno |= ME_PROJXZ;
else vlr->puno |= ME_PROJYZ;
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
}
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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex) {
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
/* 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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (vlr->puno & proj[1]) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
*adr1 = (x + 1.0f) / 2.0f;
*adr2 = (y + 1.0f) / 2.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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (vlr->puno & proj[2]) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
*adr1 = (x + 1.0f) / 2.0f;
*adr2 = (z + 1.0f) / 2.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
ret= 1;
}
else {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
*adr1 = (y + 1.0f) / 2.0f;
*adr2 = (z + 1.0f) / 2.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
ret= 2;
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +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
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;
}
/* ------------------------------------------------------------------------- */
code cleanup: use array size and const for vector args
2012-05-26 16:04:31 +00:00
static int cubemap_ob(Object *ob, const float n[3], 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;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(nor, n);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (ob) mul_mat3_m4_v3(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
Code cleanup: correct abs use also minor cleanup to rotation code
2014-04-21 01:54:52 +10:00
x1 = fabsf(nor[0]);
y1 = fabsf(nor[1]);
z1 = fabsf(nor[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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (z1>=x1 && z1>=y1) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
*adr1 = (x + 1.0f) / 2.0f;
*adr2 = (y + 1.0f) / 2.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
ret= 0;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (y1>=x1 && y1>=z1) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
*adr1 = (x + 1.0f) / 2.0f;
*adr2 = (z + 1.0f) / 2.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
ret= 1;
}
else {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
*adr1 = (y + 1.0f) / 2.0f;
*adr2 = (z + 1.0f) / 2.0f;
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
ret= 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
}
return ret;
}
/* ------------------------------------------------------------------------- */
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
static void do_2d_mapping(MTex *mtex, float texvec[3], VlakRen *vlr, const float n[3], float dxt[3], float dyt[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
{
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (R.osa==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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (wrap==MTEX_FLAT) {
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
fx = (texvec[0] + 1.0f) / 2.0f;
fy = (texvec[1] + 1.0f) / 2.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
}
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
else if (wrap == MTEX_TUBE) map_to_tube( &fx, &fy, texvec[0], texvec[1], texvec[2]);
else if (wrap == MTEX_SPHERE) map_to_sphere(&fx, &fy, texvec[0], texvec[1], texvec[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 {
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
if (texco == TEXCO_OBJECT) cubemap_ob(ob, n, texvec[0], texvec[1], texvec[2], &fx, &fy);
else if (texco == TEXCO_GLOB) cubemap_glob(n, texvec[0], texvec[1], texvec[2], &fx, &fy);
else cubemap(mtex, vlr, n, texvec[0], texvec[1], texvec[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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->flag & TEX_REPEAT_XMIR) {
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
int orig= (int)floor(origf);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (orig & 1)
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
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
}
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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->flag & TEX_REPEAT_YMIR) {
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
int orig= (int)floor(origf);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (orig & 1)
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
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
}
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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->cropxmin!=0.0f || tex->cropxmax!=1.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
fac1= tex->cropxmax - tex->cropxmin;
fx= tex->cropxmin+ fx*fac1;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->cropymin!=0.0f || tex->cropymax!=1.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
fac1= tex->cropymax - tex->cropymin;
fy= tex->cropymin+ fy*fac1;
}
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
texvec[0]= fx;
texvec[1]= 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
}
else {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (wrap==MTEX_FLAT) {
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
fx= (texvec[0] + 1.0f) / 2.0f;
fy= (texvec[1] + 1.0f) / 2.0f;
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
dxt[0]/= 2.0f;
dxt[1]/= 2.0f;
dxt[2]/= 2.0f;
dyt[0]/= 2.0f;
dyt[1]/= 2.0f;
dyt[2]/= 2.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
}
style cleanup: add braces around checks - 'if ELEM() {...}', confuses some parsers that done expand macros.
2012-03-25 22:35:18 +00:00
else if (ELEM(wrap, MTEX_TUBE, MTEX_SPHERE)) {
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have to do it themselves. This commit will need quite some testing help, but I'm around!
2003-12-21 21:52:51 +00:00
/* exception: the seam behind (y<0.0) */
ok= 1;
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
if (texvec[1]<=0.0f) {
fx= texvec[0]+dxt[0];
fy= texvec[0]+dyt[0];
if (fx>=0.0f && fy>=0.0f && texvec[0]>=0.0f) {
style cleanup: if();
2012-10-07 09:48:59 +00:00
/* pass */
}
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
else if (fx<=0.0f && fy<=0.0f && texvec[0]<=0.0f) {
style cleanup: if();
2012-10-07 09:48:59 +00:00
/* pass */
}
else {
ok = 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
}
style cleanup: if();
2012-10-07 09:48:59 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (ok) {
if (wrap==MTEX_TUBE) {
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
map_to_tube(area, area+1, texvec[0], texvec[1], texvec[2]);
map_to_tube(area + 2, area + 3, texvec[0] + dxt[0], texvec[1] + dxt[1], texvec[2] + dxt[2]);
map_to_tube(area + 4, area + 5, texvec[0] + dyt[0], texvec[1] + dyt[1], texvec[2] + 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
}
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
else {
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
map_to_sphere(area, area+1, texvec[0], texvec[1], texvec[2]);
map_to_sphere(area + 2, area + 3, texvec[0] + dxt[0], texvec[1] + dxt[1], texvec[2] + dxt[2]);
map_to_sphere(area + 4, area + 5, texvec[0] + dyt[0], texvec[1] + dyt[1], texvec[2] + 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
}
areaflag= 1;
}
else {
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
if (wrap==MTEX_TUBE) map_to_tube( &fx, &fy, texvec[0], texvec[1], texvec[2]);
else map_to_sphere(&fx, &fy, texvec[0], texvec[1], texvec[2]);
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
dxt[0]/= 2.0f;
dxt[1]/= 2.0f;
dyt[0]/= 2.0f;
dyt[1]/= 2.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
}
}
else {
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
if (texco==TEXCO_OBJECT) proj = cubemap_ob(ob, n, texvec[0], texvec[1], texvec[2], &fx, &fy);
else if (texco==TEXCO_GLOB) proj = cubemap_glob(n, texvec[0], texvec[1], texvec[2], &fx, &fy);
else proj = cubemap(mtex, vlr, n, texvec[0], texvec[1], texvec[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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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[] */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (areaflag) {
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have to do it themselves. This commit will need quite some testing help, but I'm around!
2003-12-21 21:52:51 +00:00
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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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;
style cleanup
2012-07-07 22:51:57 +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) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->flag & TEX_REPEAT_XMIR) {
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
int orig= (int)floor(origf);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (orig & 1)
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
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;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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;
style cleanup
2012-07-07 22:51:57 +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) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->flag & TEX_REPEAT_YMIR) {
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
int orig= (int)floor(origf);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (orig & 1)
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
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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (max<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
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;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->cropxmin!=0.0f || tex->cropxmax!=1.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
fac1= tex->cropxmax - tex->cropxmin;
fx= tex->cropxmin+ fx*fac1;
dxt[0]*= fac1;
dyt[0]*= fac1;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->cropymin!=0.0f || tex->cropymax!=1.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
fac1= tex->cropymax - tex->cropymin;
fy= tex->cropymin+ fy*fac1;
dxt[1]*= fac1;
dyt[1]*= fac1;
}
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
texvec[0]= fx;
texvec[1]= 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
}
}
/* ************************************** */
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
static int multitex(Tex *tex, float texvec[3], float dxt[3], float dyt[3], int osatex, TexResult *texres, const short thread, short which_output, struct ImagePool *pool, const bool skip_load_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
{
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];
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +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
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
texres->talpha = false; /* 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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->use_nodes && tex->nodetree) {
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
retval = ntreeTexExecTree(tex->nodetree, texres, texvec, dxt, dyt, osatex, thread,
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
tex, which_output, R.r.cfra, (R.r.scemode & R_TEXNODE_PREVIEW) != 0, NULL, NULL);
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
}
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
else {
switch (tex->type) {
case 0:
texres->tin= 0.0f;
return 0;
case TEX_CLOUDS:
retval = clouds(tex, texvec, texres);
break;
case TEX_WOOD:
retval = wood(tex, texvec, texres);
break;
case TEX_MARBLE:
retval = marble(tex, texvec, texres);
break;
case TEX_MAGIC:
retval = magic(tex, texvec, texres);
break;
case TEX_BLEND:
retval = blend(tex, texvec, texres);
break;
case TEX_STUCCI:
retval = stucci(tex, texvec, texres);
break;
case TEX_NOISE:
Fix T42139, vertical noise stripe patterns in noise texture. Two fixes here (only the second one is strictly needed to fix the issue, but both make the system better). First is introduction of a random generator array for use with threaded systems where each thread needs to access its own number generator. The random texture now uses this so it should not be influenced by other random generator reseedings of the main random generator like it did before. Second, I reshuffled the texture code to resample the upper bits of the random number first. According to Numerical Recipes, this is where the most variance can be found, so by sampling those we avoid correlation issues. Also, multiplying here is not ideal because if a pair of bits are zero, then the whole result will also be zero. Overall this is much more random (tm) than before, however result will also be brighter, since we now have less black spots. Tweaking the brightness/contrast should somewhat fix that, generally having the same result as before is not possible anyway if we are to really fix this. Also, seems like exposing procedural depth might be nice here since it influences the precision of the texture lookup.
2014-10-09 15:48:38 +02:00
retval = texnoise(tex, texres, thread);
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
break;
case TEX_IMAGE:
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
if (osatex) retval = imagewraposa(tex, tex->ima, NULL, texvec, dxt, dyt, texres, pool, skip_load_image);
else retval = imagewrap(tex, tex->ima, NULL, texvec, texres, pool, skip_load_image);
Fix for image garbage collection failing to run for render-only views Check for freeing old images was running per-object, move this to viewport drawing.
2014-05-22 11:58:07 +10:00
if (tex->ima) {
BKE_image_tag_time(tex->ima);
}
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
break;
case TEX_ENVMAP:
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
retval = envmaptex(tex, texvec, dxt, dyt, osatex, texres, pool, skip_load_image);
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
break;
case TEX_MUSGRAVE:
/* newnoise: musgrave types */
/* ton: added this, for Blender convention reason.
* artificer: added the use of tmpvec to avoid scaling texvec
*/
copy_v3_v3(tmpvec, texvec);
mul_v3_fl(tmpvec, 1.0f / tex->noisesize);
switch (tex->stype) {
case TEX_MFRACTAL:
case TEX_FBM:
retval = mg_mFractalOrfBmTex(tex, tmpvec, texres);
break;
case TEX_RIDGEDMF:
case TEX_HYBRIDMF:
retval = mg_ridgedOrHybridMFTex(tex, tmpvec, texres);
break;
case TEX_HTERRAIN:
retval = mg_HTerrainTex(tex, tmpvec, texres);
break;
}
break;
/* newnoise: voronoi type */
case TEX_VORONOI:
/* ton: added this, for Blender convention reason.
* artificer: added the use of tmpvec to avoid scaling texvec
*/
copy_v3_v3(tmpvec, texvec);
mul_v3_fl(tmpvec, 1.0f / tex->noisesize);
retval = voronoiTex(tex, tmpvec, texres);
break;
case TEX_DISTNOISE:
/* ton: added this, for Blender convention reason.
* artificer: added the use of tmpvec to avoid scaling texvec
*/
copy_v3_v3(tmpvec, texvec);
mul_v3_fl(tmpvec, 1.0f / tex->noisesize);
retval = mg_distNoiseTex(tex, tmpvec, texres);
break;
case TEX_POINTDENSITY:
retval = pointdensitytex(tex, texvec, texres);
break;
case TEX_VOXELDATA:
retval = voxeldatatex(tex, texvec, texres);
break;
case TEX_OCEAN:
retval = ocean_texture(tex, texvec, texres);
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
}
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)) {
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
texres->talpha = true;
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= 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
}
Fix #36058: Displace Modifier errors using a baked Image and displace baking inconsistency between 2.67/2.68RC and previous versions This was in fact really nasty bug, caused by multitex_nodes function using global variable R (which is a copy of current renderer). this variable is not initialized to anything meaningful for until first rendering (preview or final) happened. Since multitex_nodes might be used outside of render pipeline, made it so whether CM is on or off as an argument to functions multitex_ext_safe and multitex_ext. Now multitex_nodes() is only shall be used for stuff happening from render pipeline! Also needed to make some changes to other places, so all the usages of texture sampling knows for the fact whether CM is on or off. And one more change is related on behavior of dispalcement, wave, warp, weightvg modifiers and smoke. They'll be always using CM off since texture is used for influence, not for color. It's rather bigger patch, but it's mostly straightforward changes, which we really need to be done. Reviewed by Brecht, thanks!
2013-07-15 14:47:58 +00:00
static int multitex_nodes_intern(Tex *tex, float texvec[3], float dxt[3], float dyt[3], int osatex, TexResult *texres,
const short thread, short which_output, ShadeInput *shi, MTex *mtex, struct ImagePool *pool,
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
bool scene_color_manage, const bool skip_load_image)
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
{
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex==NULL) {
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
memset(texres, 0, sizeof(TexResult));
return 0;
}
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex)
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
which_output= mtex->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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->type==TEX_IMAGE) {
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
int rgbnor;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex) {
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
/* we have mtex, use it for 2d mapping images only */
do_2d_mapping(mtex, texvec, shi->vlr, shi->facenor, dxt, dyt);
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
rgbnor = multitex(tex, texvec, dxt, dyt, osatex, texres, thread, which_output, pool, skip_load_image);
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & (MAP_COL+MAP_COLSPEC+MAP_COLMIR)) {
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
ImBuf *ibuf = BKE_image_pool_acquire_ibuf(tex->ima, &tex->iuser, pool);
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
/* don't linearize float buffers, assumed to be linear */
Fix #36058: Displace Modifier errors using a baked Image and displace baking inconsistency between 2.67/2.68RC and previous versions This was in fact really nasty bug, caused by multitex_nodes function using global variable R (which is a copy of current renderer). this variable is not initialized to anything meaningful for until first rendering (preview or final) happened. Since multitex_nodes might be used outside of render pipeline, made it so whether CM is on or off as an argument to functions multitex_ext_safe and multitex_ext. Now multitex_nodes() is only shall be used for stuff happening from render pipeline! Also needed to make some changes to other places, so all the usages of texture sampling knows for the fact whether CM is on or off. And one more change is related on behavior of dispalcement, wave, warp, weightvg modifiers and smoke. They'll be always using CM off since texture is used for influence, not for color. It's rather bigger patch, but it's mostly straightforward changes, which we really need to be done. Reviewed by Brecht, thanks!
2013-07-15 14:47:58 +00:00
if (ibuf && !(ibuf->rect_float) && scene_color_manage)
Color Management, Stage 2: Switch color pipeline to use OpenColorIO Replace old color pipeline which was supporting linear/sRGB color spaces only with OpenColorIO-based pipeline. This introduces two configurable color spaces: - Input color space for images and movie clips. This space is used to convert images/movies from color space in which file is saved to Blender's linear space (for float images, byte images are not internally converted, only input space is stored for such images and used later). This setting could be found in image/clip data block settings. - Display color space which defines space in which particular display is working. This settings could be found in scene's Color Management panel. When render result is being displayed on the screen, apart from converting image to display space, some additional conversions could happen. This conversions are: - View, which defines tone curve applying before display transformation. These are different ways to view the image on the same display device. For example it could be used to emulate film view on sRGB display. - Exposure affects on image exposure before tone map is applied. - Gamma is post-display gamma correction, could be used to match particular display gamma. - RGB curves are user-defined curves which are applying before display transformation, could be used for different purposes. All this settings by default are only applying on render result and does not affect on other images. If some particular image needs to be affected by this transformation, "View as Render" setting of image data block should be set to truth. Movie clips are always affected by all display transformations. This commit also introduces configurable color space in which sequencer is working. This setting could be found in scene's Color Management panel and it should be used if such stuff as grading needs to be done in color space different from sRGB (i.e. when Film view on sRGB display is use, using VD16 space as sequencer's internal space would make grading working in space which is close to the space using for display). Some technical notes: - Image buffer's float buffer is now always in linear space, even if it was created from 16bit byte images. - Space of byte buffer is stored in image buffer's rect_colorspace property. - Profile of image buffer was removed since it's not longer meaningful. - OpenGL and GLSL is supposed to always work in sRGB space. It is possible to support other spaces, but it's quite large project which isn't so much important. - Legacy Color Management option disabled is emulated by using None display. It could have some regressions, but there's no clear way to avoid them. - If OpenColorIO is disabled on build time, it should make blender behaving in the same way as previous release with color management enabled. More details could be found at this page (more details would be added soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management -- Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO integration and to Brecht van Lommel for some further development and code/ usecase review!
2012-09-15 10:05:07 +00:00
IMB_colormanagement_colorspace_to_scene_linear_v3(&texres->tr, ibuf->rect_colorspace);
Image thread safe improvements This commit makes BKE_image_acquire_ibuf referencing result, which means once some area requested for image buffer, it'll be guaranteed this buffer wouldn't be freed by image signal. To de-reference buffer BKE_image_release_ibuf should now always be used. To make referencing working correct we can not rely on result of image_get_ibuf_threadsafe called outside from thread lock. This is so because we need to guarantee getting image buffer from list of loaded buffers and it's referencing happens atomic. Without lock here it is possible that between call of image_get_ibuf_threadsafe and referencing the buffer IMA_SIGNAL_FREE would be called. Image signal handling too is blocking now to prevent such a situation. Threads are locking by spinlock, which are faster than mutexes. There were some slowdown reports in the past about render slowdown when using OSX on Xeon CPU. It shouldn't happen with spin locks, but more tests on different hardware would be really welcome. So far can not see speed regressions on own computers. This commit also removes BKE_image_get_ibuf, because it was not so intuitive when get_ibuf and acquire_ibuf should be used. Thanks to Ton and Brecht for discussion/review :)
2012-11-15 15:59:58 +00:00
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
BKE_image_pool_release_ibuf(tex->ima, ibuf, pool);
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
}
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
}
else {
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
/* we don't have mtex, do default flat 2d projection */
MTex localmtex;
float texvec_l[3], dxt_l[3], dyt_l[3];
localmtex.mapping= MTEX_FLAT;
localmtex.tex= tex;
localmtex.object= NULL;
localmtex.texco= TEXCO_ORCO;
Fix #21227, #21346 and #21336: image texture wasn't centered correctly when sculpting and using it from material nodes.
2010-03-01 18:11:09 +00:00
copy_v3_v3(texvec_l, texvec);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (dxt && dyt) {
Fix #21227, #21346 and #21336: image texture wasn't centered correctly when sculpting and using it from material nodes.
2010-03-01 18:11:09 +00:00
copy_v3_v3(dxt_l, dxt);
copy_v3_v3(dyt_l, dyt);
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
}
else {
Fix #21227, #21346 and #21336: image texture wasn't centered correctly when sculpting and using it from material nodes.
2010-03-01 18:11:09 +00:00
zero_v3(dxt_l);
zero_v3(dyt_l);
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
}
do_2d_mapping(&localmtex, texvec_l, NULL, NULL, dxt_l, dyt_l);
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
rgbnor = multitex(tex, texvec_l, dxt_l, dyt_l, osatex, texres, thread, which_output, pool, skip_load_image);
Fix #32930: texture colors in material nodes (blender internal) are brighter than normal There was a missing byte buffer linearization for shader nodes. Also fixed incorrect image input color space refresh when image is packed.
2012-10-22 17:34:06 +00:00
{
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
ImBuf *ibuf = BKE_image_pool_acquire_ibuf(tex->ima, &tex->iuser, pool);
Fix #32930: texture colors in material nodes (blender internal) are brighter than normal There was a missing byte buffer linearization for shader nodes. Also fixed incorrect image input color space refresh when image is packed.
2012-10-22 17:34:06 +00:00
/* don't linearize float buffers, assumed to be linear */
Fix #36058: Displace Modifier errors using a baked Image and displace baking inconsistency between 2.67/2.68RC and previous versions This was in fact really nasty bug, caused by multitex_nodes function using global variable R (which is a copy of current renderer). this variable is not initialized to anything meaningful for until first rendering (preview or final) happened. Since multitex_nodes might be used outside of render pipeline, made it so whether CM is on or off as an argument to functions multitex_ext_safe and multitex_ext. Now multitex_nodes() is only shall be used for stuff happening from render pipeline! Also needed to make some changes to other places, so all the usages of texture sampling knows for the fact whether CM is on or off. And one more change is related on behavior of dispalcement, wave, warp, weightvg modifiers and smoke. They'll be always using CM off since texture is used for influence, not for color. It's rather bigger patch, but it's mostly straightforward changes, which we really need to be done. Reviewed by Brecht, thanks!
2013-07-15 14:47:58 +00:00
if (ibuf && !(ibuf->rect_float) && scene_color_manage)
Fix #32930: texture colors in material nodes (blender internal) are brighter than normal There was a missing byte buffer linearization for shader nodes. Also fixed incorrect image input color space refresh when image is packed.
2012-10-22 17:34:06 +00:00
IMB_colormanagement_colorspace_to_scene_linear_v3(&texres->tr, ibuf->rect_colorspace);
Image thread safe improvements This commit makes BKE_image_acquire_ibuf referencing result, which means once some area requested for image buffer, it'll be guaranteed this buffer wouldn't be freed by image signal. To de-reference buffer BKE_image_release_ibuf should now always be used. To make referencing working correct we can not rely on result of image_get_ibuf_threadsafe called outside from thread lock. This is so because we need to guarantee getting image buffer from list of loaded buffers and it's referencing happens atomic. Without lock here it is possible that between call of image_get_ibuf_threadsafe and referencing the buffer IMA_SIGNAL_FREE would be called. Image signal handling too is blocking now to prevent such a situation. Threads are locking by spinlock, which are faster than mutexes. There were some slowdown reports in the past about render slowdown when using OSX on Xeon CPU. It shouldn't happen with spin locks, but more tests on different hardware would be really welcome. So far can not see speed regressions on own computers. This commit also removes BKE_image_get_ibuf, because it was not so intuitive when get_ibuf and acquire_ibuf should be used. Thanks to Ton and Brecht for discussion/review :)
2012-11-15 15:59:58 +00:00
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
BKE_image_pool_release_ibuf(tex->ima, ibuf, pool);
Fix #32930: texture colors in material nodes (blender internal) are brighter than normal There was a missing byte buffer linearization for shader nodes. Also fixed incorrect image input color space refresh when image is packed.
2012-10-22 17:34:06 +00:00
}
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
}
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
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
return rgbnor;
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
}
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
else {
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
return multitex(tex, texvec, dxt, dyt, osatex, texres, thread, which_output, pool, skip_load_image);
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +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
}
Fix #36058: Displace Modifier errors using a baked Image and displace baking inconsistency between 2.67/2.68RC and previous versions This was in fact really nasty bug, caused by multitex_nodes function using global variable R (which is a copy of current renderer). this variable is not initialized to anything meaningful for until first rendering (preview or final) happened. Since multitex_nodes might be used outside of render pipeline, made it so whether CM is on or off as an argument to functions multitex_ext_safe and multitex_ext. Now multitex_nodes() is only shall be used for stuff happening from render pipeline! Also needed to make some changes to other places, so all the usages of texture sampling knows for the fact whether CM is on or off. And one more change is related on behavior of dispalcement, wave, warp, weightvg modifiers and smoke. They'll be always using CM off since texture is used for influence, not for color. It's rather bigger patch, but it's mostly straightforward changes, which we really need to be done. Reviewed by Brecht, thanks!
2013-07-15 14:47:58 +00:00
/* this is called from the shader and texture nodes
* Use it from render pipeline only!
*/
int multitex_nodes(Tex *tex, float texvec[3], float dxt[3], float dyt[3], int osatex, TexResult *texres,
const short thread, short which_output, ShadeInput *shi, MTex *mtex, struct ImagePool *pool)
{
return multitex_nodes_intern(tex, texvec, dxt, dyt, osatex, texres,
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
thread, which_output, shi, mtex, pool, R.scene_color_manage,
(R.r.scemode & R_NO_IMAGE_LOAD) != 0);
Fix #36058: Displace Modifier errors using a baked Image and displace baking inconsistency between 2.67/2.68RC and previous versions This was in fact really nasty bug, caused by multitex_nodes function using global variable R (which is a copy of current renderer). this variable is not initialized to anything meaningful for until first rendering (preview or final) happened. Since multitex_nodes might be used outside of render pipeline, made it so whether CM is on or off as an argument to functions multitex_ext_safe and multitex_ext. Now multitex_nodes() is only shall be used for stuff happening from render pipeline! Also needed to make some changes to other places, so all the usages of texture sampling knows for the fact whether CM is on or off. And one more change is related on behavior of dispalcement, wave, warp, weightvg modifiers and smoke. They'll be always using CM off since texture is used for influence, not for color. It's rather bigger patch, but it's mostly straightforward changes, which we really need to be done. Reviewed by Brecht, thanks!
2013-07-15 14:47:58 +00:00
}
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
/* this is called for surface shading */
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
static int multitex_mtex(ShadeInput *shi, MTex *mtex, float texvec[3], float dxt[3], float dyt[3], TexResult *texres, struct ImagePool *pool, const bool skip_load_image)
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
{
quiet -Wmissing-prototypes warnings, and enable this warning by default for C with gcc. helps for finding unused functions and making functions static, also did some minor code cleanup.
2012-09-15 01:52:28 +00:00
Tex *tex = mtex->tex;
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->use_nodes && tex->nodetree) {
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
/* stupid exception here .. but we have to pass shi and mtex to
style cleanup: comment blocks
2012-03-09 18:28:30 +00:00
* textures nodes for 2d mapping and color management for images */
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
return ntreeTexExecTree(tex->nodetree, texres, texvec, dxt, dyt, shi->osatex, shi->thread,
quiet -Wmissing-prototypes warnings, and enable this warning by default for C with gcc. helps for finding unused functions and making functions static, also did some minor code cleanup.
2012-09-15 01:52:28 +00:00
tex, mtex->which_output, R.r.cfra, (R.r.scemode & R_TEXNODE_PREVIEW) != 0, shi, mtex);
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
}
quiet -Wmissing-prototypes warnings, and enable this warning by default for C with gcc. helps for finding unused functions and making functions static, also did some minor code cleanup.
2012-09-15 01:52:28 +00:00
else {
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
return multitex(mtex->tex, texvec, dxt, dyt, shi->osatex, texres, shi->thread, mtex->which_output, pool, skip_load_image);
quiet -Wmissing-prototypes warnings, and enable this warning by default for C with gcc. helps for finding unused functions and making functions static, also did some minor code cleanup.
2012-09-15 01:52:28 +00:00
}
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
}
/* Warning, if the texres's values are not declared zero, check the return value to be sure
Fix #36058: Displace Modifier errors using a baked Image and displace baking inconsistency between 2.67/2.68RC and previous versions This was in fact really nasty bug, caused by multitex_nodes function using global variable R (which is a copy of current renderer). this variable is not initialized to anything meaningful for until first rendering (preview or final) happened. Since multitex_nodes might be used outside of render pipeline, made it so whether CM is on or off as an argument to functions multitex_ext_safe and multitex_ext. Now multitex_nodes() is only shall be used for stuff happening from render pipeline! Also needed to make some changes to other places, so all the usages of texture sampling knows for the fact whether CM is on or off. And one more change is related on behavior of dispalcement, wave, warp, weightvg modifiers and smoke. They'll be always using CM off since texture is used for influence, not for color. It's rather bigger patch, but it's mostly straightforward changes, which we really need to be done. Reviewed by Brecht, thanks!
2013-07-15 14:47:58 +00:00
* the color values are set before using the r/g/b values, otherwise you may use uninitialized values - Campbell
*
* Use it for stuff which is out of render pipeline.
*/
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
int multitex_ext(Tex *tex, float texvec[3], float dxt[3], float dyt[3], int osatex, TexResult *texres, struct ImagePool *pool, bool scene_color_manage, const bool skip_load_image)
Bugfix #25392 Compositor: Texture node didn't use texture-nodes itself. Now composites initialize texture nodes correctly. Also reviewed the fix for crashing texture nodes for displace. It appears texture nodes also are used for sculpt/paint brushes, in these cases it can be allowed again. But, don't do this during rendering for now!
2010-12-27 19:26:38 +00:00
{
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
return multitex_nodes_intern(tex, texvec, dxt, dyt, osatex, texres, 0, 0, NULL, NULL, pool, scene_color_manage, skip_load_image);
Bugfix #25392 Compositor: Texture node didn't use texture-nodes itself. Now composites initialize texture nodes correctly. Also reviewed the fix for crashing texture nodes for displace. It appears texture nodes also are used for sculpt/paint brushes, in these cases it can be allowed again. But, don't do this during rendering for now!
2010-12-27 19:26:38 +00:00
}
Fix #36058: Displace Modifier errors using a baked Image and displace baking inconsistency between 2.67/2.68RC and previous versions This was in fact really nasty bug, caused by multitex_nodes function using global variable R (which is a copy of current renderer). this variable is not initialized to anything meaningful for until first rendering (preview or final) happened. Since multitex_nodes might be used outside of render pipeline, made it so whether CM is on or off as an argument to functions multitex_ext_safe and multitex_ext. Now multitex_nodes() is only shall be used for stuff happening from render pipeline! Also needed to make some changes to other places, so all the usages of texture sampling knows for the fact whether CM is on or off. And one more change is related on behavior of dispalcement, wave, warp, weightvg modifiers and smoke. They'll be always using CM off since texture is used for influence, not for color. It's rather bigger patch, but it's mostly straightforward changes, which we really need to be done. Reviewed by Brecht, thanks!
2013-07-15 14:47:58 +00:00
/* extern-tex doesn't support nodes (ntreeBeginExec() can't be called when rendering is going on)\
*
* Use it for stuff which is out of render pipeline.
*/
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
int multitex_ext_safe(Tex *tex, float texvec[3], TexResult *texres, struct ImagePool *pool, bool scene_color_manage, const bool skip_load_image)
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
{
Bug #22585 Using texture nodes for displacement crashes, a conflict between using nodes in render and for displacement at same time. Code simply disables texture nodes for displacement for now, until we have better handling for it. (on our long todo)
2010-11-16 13:41:39 +00:00
int use_nodes= tex->use_nodes, retval;
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
tex->use_nodes = false;
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
retval= multitex_nodes_intern(tex, texvec, NULL, NULL, 0, texres, 0, 0, NULL, NULL, pool, scene_color_manage, skip_load_image);
Bug #22585 Using texture nodes for displacement crashes, a conflict between using nodes in render and for displacement at same time. Code simply disables texture nodes for displacement for now, until we have better handling for it. (on our long todo)
2010-11-16 13:41:39 +00:00
tex->use_nodes= use_nodes;
return retval;
Texture Nodes: * Remove the manual OSA method but rather pass on derivatives to the textures. This means that at the moment e.g. the bricks node is not antialiased, but that image textures are now using mipmaps. Doing oversampling on the whole nodetree is convenient but it is really the individual textures that can do filtering best and quickest. * Image textures in a texture node tree were not color corrected and did not support 2d mapping, now it's passing along shadeinput to make this possible. Would like to avoid this but not sure how. * Fix preview not filling in all pixels when scaling or rotating in the texture nodes.
2010-02-16 15:45:19 +00:00
}
Bugfix #25392 Compositor: Texture node didn't use texture-nodes itself. Now composites initialize texture nodes correctly. Also reviewed the fix for crashing texture nodes for displace. It appears texture nodes also are used for sculpt/paint brushes, in these cases it can be allowed again. But, don't do this during rendering for now!
2010-12-27 19:26:38 +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 */
use vector size and const args where possible (no functional change)
2011-09-12 13:00:24 +00:00
void texture_rgb_blend(float in[3], const float tex[3], const float out[3], 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
style cleanup: changes to brace placement / newlines - for/while/if/switch
2012-04-28 06:31:57 +00:00
switch (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
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;
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
facm= 1.0f-fact;
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
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;
Bug fix #33639 Material Texture blend modes Screen, Overlay and Multiply didn't respect the alpha for textures... an error I could trace back to 2004 even. Obviously the fix should be done, but it might change the appearance of renders somewhat. Will keep an eye open if this is worth ugly version-patching. Now: image textures with alpha, will only apply the blend modes respecting the alpha values.
2012-12-21 10:15:12 +00:00
facm= 1.0f-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]= (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;
Bug fix #33639 Material Texture blend modes Screen, Overlay and Multiply didn't respect the alpha for textures... an error I could trace back to 2004 even. Obviously the fix should be done, but it might change the appearance of renders somewhat. Will keep an eye open if this is worth ugly version-patching. Now: image textures with alpha, will only apply the blend modes respecting the alpha values.
2012-12-21 10:15:12 +00:00
facm= 1.0f-fact;
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
in[0]= 1.0f - (facm+fact*(1.0f-tex[0])) * (1.0f-out[0]);
in[1]= 1.0f - (facm+fact*(1.0f-tex[1])) * (1.0f-out[1]);
in[2]= 1.0f - (facm+fact*(1.0f-tex[2])) * (1.0f-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;
Bug fix #33639 Material Texture blend modes Screen, Overlay and Multiply didn't respect the alpha for textures... an error I could trace back to 2004 even. Obviously the fix should be done, but it might change the appearance of renders somewhat. Will keep an eye open if this is worth ugly version-patching. Now: image textures with alpha, will only apply the blend modes respecting the alpha values.
2012-12-21 10:15:12 +00:00
facm= 1.0f-fact;
Blending mode "Overlay" was not coded yet for material blending.
2007-12-03 16:06:34 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (out[0] < 0.5f)
Blending mode "Overlay" was not coded yet for material blending.
2007-12-03 16:06:34 +00:00
in[0] = out[0] * (facm + 2.0f*fact*tex[0]);
else
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
in[0] = 1.0f - (facm + 2.0f*fact*(1.0f - tex[0])) * (1.0f - out[0]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (out[1] < 0.5f)
Blending mode "Overlay" was not coded yet for material blending.
2007-12-03 16:06:34 +00:00
in[1] = out[1] * (facm + 2.0f*fact*tex[1]);
else
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
in[1] = 1.0f - (facm + 2.0f*fact*(1.0f - tex[1])) * (1.0f - out[1]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (out[2] < 0.5f)
Blending mode "Overlay" was not coded yet for material blending.
2007-12-03 16:06:34 +00:00
in[2] = out[2] * (facm + 2.0f*fact*tex[2]);
else
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
in[2] = 1.0f - (facm + 2.0f*fact*(1.0f - tex[2])) * (1.0f - out[2]);
Blending mode "Overlay" was not coded yet for material blending.
2007-12-03 16:06:34 +00:00
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;
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
facm= 1.0f-fact;
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex[0]!=0.0f)
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
in[0]= facm*out[0] + fact*out[0]/tex[0];
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex[1]!=0.0f)
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
in[1]= facm*out[1] + fact*out[1]/tex[1];
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex[2]!=0.0f)
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
in[2]= facm*out[2] + fact*out[2]/tex[2];
break;
case MTEX_DIFF:
fact*= facg;
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
facm= 1.0f-fact;
quiet -Wdouble-promotion warnings
2011-11-11 12:00:08 +00:00
in[0]= facm*out[0] + fact*fabsf(tex[0]-out[0]);
in[1]= facm*out[1] + fact*fabsf(tex[1]-out[1]);
in[2]= facm*out[2] + fact*fabsf(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_DARK:
fact*= facg;
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
facm= 1.0f-fact;
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
Fix for wrong behavior of 'darken' blend mode with factor. The formula was not consistent across Blender and behaved strangely, now it is a simple linear blend between color1 and min(color1, color2). Reviewed By: brecht Differential Revision: https://developer.blender.org/D489
2014-04-28 17:38:34 +02:00
in[0] = min_ff(out[0], tex[0])*fact + out[0]*facm;
in[1] = min_ff(out[1], tex[1])*fact + out[1]*facm;
in[2] = min_ff(out[2], tex[2])*fact + out[2]*facm;
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_LIGHT:
fact*= facg;
col= fact*tex[0];
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (col > out[0]) in[0]= col; else in[0]= out[0];
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
col= fact*tex[1];
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (col > out[1]) in[1]= col; else in[1]= out[1];
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
col= fact*tex[2];
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (col > out[2]) in[2]= col; else in[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;
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;
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(in, out);
minor edit - weight_to_rgb() and ramp_blend() now take a float vector rather than 3 float pointers. also make particle draw use a float vec.
2011-11-26 03:13:54 +00:00
ramp_blend(MA_RAMP_HUE, in, fact, tex);
Adding the colorband Hue, Saturation, Value, Color blending modes to the Material Texture blending as well.
2008-01-10 11:26:17 +00:00
break;
case MTEX_BLEND_SAT:
fact*= facg;
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(in, out);
minor edit - weight_to_rgb() and ramp_blend() now take a float vector rather than 3 float pointers. also make particle draw use a float vec.
2011-11-26 03:13:54 +00:00
ramp_blend(MA_RAMP_SAT, in, fact, tex);
Adding the colorband Hue, Saturation, Value, Color blending modes to the Material Texture blending as well.
2008-01-10 11:26:17 +00:00
break;
case MTEX_BLEND_VAL:
fact*= facg;
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(in, out);
minor edit - weight_to_rgb() and ramp_blend() now take a float vector rather than 3 float pointers. also make particle draw use a float vec.
2011-11-26 03:13:54 +00:00
ramp_blend(MA_RAMP_VAL, in, fact, tex);
Adding the colorband Hue, Saturation, Value, Color blending modes to the Material Texture blending as well.
2008-01-10 11:26:17 +00:00
break;
case MTEX_BLEND_COLOR:
fact*= facg;
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(in, out);
minor edit - weight_to_rgb() and ramp_blend() now take a float vector rather than 3 float pointers. also make particle draw use a float vec.
2011-11-26 03:13:54 +00:00
ramp_blend(MA_RAMP_COLOR, in, fact, tex);
Adding the colorband Hue, Saturation, Value, Color blending modes to the Material Texture blending as well.
2008-01-10 11:26:17 +00:00
break;
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
case MTEX_SOFT_LIGHT:
fact*= facg;
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(in, out);
minor edit - weight_to_rgb() and ramp_blend() now take a float vector rather than 3 float pointers. also make particle draw use a float vec.
2011-11-26 03:13:54 +00:00
ramp_blend(MA_RAMP_SOFT, in, fact, tex);
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
break;
case MTEX_LIN_LIGHT:
fact*= facg;
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(in, out);
minor edit - weight_to_rgb() and ramp_blend() now take a float vector rather than 3 float pointers. also make particle draw use a float vec.
2011-11-26 03:13:54 +00:00
ramp_blend(MA_RAMP_LINEAR, in, fact, tex);
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
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
}
}
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float texture_value_blend(float tex, float out, float fact, float facg, int blendtype)
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;
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
int flip= (facg < 0.0f);
facg= fabsf(facg);
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;
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
facm= 1.0f-fact;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (flip) SWAP(float, fact, facm);
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
style cleanup: changes to brace placement / newlines - for/while/if/switch
2012-04-28 06:31:57 +00:00
switch (blendtype) {
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
case MTEX_BLEND:
in= fact*tex + facm*out;
break;
case MTEX_MUL:
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
facm= 1.0f-facg;
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
in= (facm+fact*tex)*out;
break;
case MTEX_SCREEN:
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
facm= 1.0f-facg;
in= 1.0f-(facm+fact*(1.0f-tex))*(1.0f-out);
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
break;
Fix #20305: overlay blending mode for specular intensity does not work.
2009-12-09 19:41:27 +00:00
case MTEX_OVERLAY:
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
facm= 1.0f-facg;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (out < 0.5f)
Fix #20305: overlay blending mode for specular intensity does not work.
2009-12-09 19:41:27 +00:00
in = out * (facm + 2.0f*fact*tex);
else
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
in = 1.0f - (facm + 2.0f*fact*(1.0f - tex)) * (1.0f - out);
Fix #20305: overlay blending mode for specular intensity does not work.
2009-12-09 19:41:27 +00:00
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
case MTEX_SUB:
fact= -fact;
case MTEX_ADD:
in= fact*tex + out;
break;
case MTEX_DIV:
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex!=0.0f)
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
in= facm*out + fact*out/tex;
break;
case MTEX_DIFF:
quiet -Wdouble-promotion warnings
2011-11-11 12:00:08 +00:00
in= facm*out + fact*fabsf(tex-out);
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
break;
case MTEX_DARK:
Fix for wrong behavior of 'darken' blend mode with factor. The formula was not consistent across Blender and behaved strangely, now it is a simple linear blend between color1 and min(color1, color2). Reviewed By: brecht Differential Revision: https://developer.blender.org/D489
2014-04-28 17:38:34 +02:00
in = min_ff(out, tex)*fact + out*facm;
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
break;
case MTEX_LIGHT:
col= fact*tex;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (col > out) in= col; else in= out;
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
break;
committing patch #19252-Soft/Linear Light blend modes+Darken mode bug fix
2009-09-10 03:00:50 +00:00
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
case MTEX_SOFT_LIGHT:
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
scf=1.0f - (1.0f - tex) * (1.0f - out);
in= facm*out + fact * ((1.0f - out) * tex * out) + (out * scf);
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
break;
case MTEX_LIN_LIGHT:
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
if (tex > 0.5f)
in = out + fact*(2.0f*(tex - 0.5f));
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
else
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
in = out + fact*(2.0f*tex - 1.0f);
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
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;
}
style cleanup: also rename mesh_getVertexCos() --> BKE_mesh_vertexCos_get() to match curve function.
2013-03-26 07:29:01 +00:00
static void texco_mapping(ShadeInput *shi, Tex *tex, MTex *mtex,
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
const float co[3], const float dx[3], const float dy[3], float texvec[3], float dxt[3], float dyt[3])
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
{
style cleanup
2012-07-07 22:51:57 +00:00
/* new: first swap coords, then map, then trans/scale */
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 (tex->type == TEX_IMAGE) {
style cleanup
2012-07-07 22:51:57 +00:00
/* placement */
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] = 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);
style cleanup
2012-07-07 22:51:57 +00:00
/* translate and scale */
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] = 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) {
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
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];
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
}
/* problem: repeat-mirror is not a 'repeat' but 'extend' in imagetexture.c */
style cleanup
2012-07-07 22:51:57 +00:00
/* 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) */
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 (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)
style cleanup
2012-07-07 22:51:57 +00:00
texvec[0] -= floorf(texvec[0]); /* this line equivalent to old code, same below */
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 (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)) {
style cleanup
2012-04-21 12:51:47 +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];
}
}
}
style cleanup
2012-07-07 22:51:57 +00:00
else { /* procedural */
/* placement */
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] = 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];
}
Fix for unitialized variable and resulting render artifacts when setting project x/y/z to none with a procedural texture.
2009-11-20 15:07:16 +00:00
else dxt[0] = dyt[0] = 0.f;
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->projy) {
dxt[1] = mtex->size[1]*dx[mtex->projy - 1];
dyt[1] = mtex->size[1]*dy[mtex->projy - 1];
}
Fix for unitialized variable and resulting render artifacts when setting project x/y/z to none with a procedural texture.
2009-11-20 15:07:16 +00:00
else dxt[1] = dyt[1] = 0.f;
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->projz) {
dxt[2] = mtex->size[2]*dx[mtex->projz - 1];
dyt[2] = mtex->size[2]*dy[mtex->projz - 1];
}
Fix for unitialized variable and resulting render artifacts when setting project x/y/z to none with a procedural texture.
2009-11-20 15:07:16 +00:00
else dxt[2]= dyt[2] = 0.f;
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
}
}
}
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
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
/* Bump code from 2.5 development cycle, has a number of bugs, but here for compatibility */
typedef struct CompatibleBump {
float nu[3], nv[3], nn[3];
float dudnu, dudnv, dvdnu, dvdnv;
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
bool nunvdone;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
} CompatibleBump;
static void compatible_bump_init(CompatibleBump *compat_bump)
{
memset(compat_bump, 0, sizeof(*compat_bump));
compat_bump->dudnu = 1.0f;
compat_bump->dvdnv = 1.0f;
}
static void compatible_bump_uv_derivs(CompatibleBump *compat_bump, ShadeInput *shi, MTex *mtex, int i)
{
style cleanup
2012-07-07 22:51:57 +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.. */
/* NOTE: shi->v1 is NULL when called from displace_render_vert,
* assigning verts in this case is not trivial because the shi quad face side is not know. */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
if ((mtex->texflag & MTEX_COMPAT_BUMP) && shi->obr && shi->obr->ob && shi->v1) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & (MAP_NORM|MAP_WARP) && !((mtex->tex->type==TEX_IMAGE) && (mtex->tex->imaflag & TEX_NORMALMAP))) {
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
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);
style cleanup
2012-07-07 22:51:57 +00:00
/* compute ortho basis around normal */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (!compat_bump->nunvdone) {
style cleanup
2012-07-07 22:51:57 +00:00
/* render normal is negated */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
compat_bump->nn[0] = -shi->vn[0];
compat_bump->nn[1] = -shi->vn[1];
compat_bump->nn[2] = -shi->vn[2];
ortho_basis_v3v3_v3(compat_bump->nu, compat_bump->nv, compat_bump->nn);
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
compat_bump->nunvdone = true;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
}
if (tf) {
Code cleanup: use 'const' for arrays (render)
2014-04-27 00:22:07 +10:00
const float *uv1 = tf->uv[j1], *uv2 = tf->uv[j2], *uv3 = tf->uv[j3];
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
const float an[3] = {fabsf(compat_bump->nn[0]), fabsf(compat_bump->nn[1]), fabsf(compat_bump->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;
compat_bump->dudnu = (dpdv_a2*compat_bump->nu[a1] - dpdv_a1*compat_bump->nu[a2])*d;
compat_bump->dvdnu = (dpdu_a1*compat_bump->nu[a2] - dpdu_a2*compat_bump->nu[a1])*d;
compat_bump->dudnv = (dpdv_a2*compat_bump->nv[a1] - dpdv_a1*compat_bump->nv[a2])*d;
compat_bump->dvdnv = (dpdu_a1*compat_bump->nv[a2] - dpdu_a2*compat_bump->nv[a1])*d;
}
}
}
}
code cleanup: use float sizes for function args.
2012-10-15 23:11:59 +00:00
static int compatible_bump_compute(CompatibleBump *compat_bump, ShadeInput *shi, MTex *mtex, Tex *tex, TexResult *texres,
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
float Tnor, const float co[3], const float dx[3], const float dy[3], float texvec[3], float dxt[3], float dyt[3],
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
struct ImagePool *pool, const bool skip_load_image)
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
{
style cleanup
2012-07-07 22:51:57 +00:00
TexResult ttexr = {0, 0, 0, 0, 0, texres->talpha, NULL}; /* temp TexResult */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
float tco[3], texv[3], cd, ud, vd, du, dv, idu, idv;
const int fromrgb = ((tex->type == TEX_IMAGE) || ((tex->flag & TEX_COLORBAND)!=0));
Bump maps flip: now white means salience, black means concavity Files created in blender before this revision should be rendered in exactly the same way they used to render before. Patch by Morten Mikkelsen, finished by Ton and me.
2011-09-30 09:55:21 +00:00
const float bf = -0.04f*Tnor*mtex->norfac;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
int rgbnor;
style cleanup
2012-07-07 22:51:57 +00:00
/* disable internal bump eval */
style cleanup
2013-10-16 04:08:20 +00:00
float *nvec = texres->nor;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
texres->nor = NULL;
style cleanup
2012-07-07 22:51:57 +00:00
/* du & dv estimates, constant value defaults */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
du = dv = 0.01f;
style cleanup
2012-07-07 22:51:57 +00:00
/* compute ortho basis around normal */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (!compat_bump->nunvdone) {
style cleanup
2012-07-07 22:51:57 +00:00
/* render normal is negated */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
negate_v3_v3(compat_bump->nn, shi->vn);
ortho_basis_v3v3_v3(compat_bump->nu, compat_bump->nv, compat_bump->nn);
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
compat_bump->nunvdone = true;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
}
style cleanup
2012-07-07 22:51:57 +00:00
/* 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... */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
if (!shi->osatex && (tex->type == TEX_IMAGE) && tex->ima) {
style cleanup
2012-07-07 22:51:57 +00:00
/* in case we have no proper derivatives, fall back to
* computing du/dv it based on image size */
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
ImBuf *ibuf = BKE_image_pool_acquire_ibuf(tex->ima, &tex->iuser, pool);
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
if (ibuf) {
du = 1.f/(float)ibuf->x;
dv = 1.f/(float)ibuf->y;
}
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
BKE_image_pool_release_ibuf(tex->ima, ibuf, pool);
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
}
else if (shi->osatex) {
style cleanup
2012-07-07 22:51:57 +00:00
/* we have derivatives, can compute proper du/dv */
if (tex->type == TEX_IMAGE) { /* 2d image, use u & v max. of dx/dy 2d vecs */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
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]);
}
style cleanup
2012-07-07 22:51:57 +00:00
else { /* 3d procedural, estimate from all dx/dy elems */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
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])};
replace MIN/MAX 3,4 with inline functions
2012-12-21 05:07:26 +00:00
du = max_fff(adx[0], adx[1], adx[2]);
dv = max_fff(ady[0], ady[1], ady[2]);
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
}
}
style cleanup
2012-07-07 22:51:57 +00:00
/* center, main return value */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
texco_mapping(shi, tex, mtex, co, dx, dy, texvec, dxt, dyt);
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
rgbnor = multitex_mtex(shi, mtex, texvec, dxt, dyt, texres, pool, skip_load_image);
Divide by 3 instead of multiplying by variations of 0.333 Fixes small precision problems.
2013-02-14 17:35:43 +00:00
cd = fromrgb ? (texres->tr + texres->tg + texres->tb) / 3.0f : texres->tin;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
if (mtex->texco == TEXCO_UV) {
style cleanup
2012-07-07 22:51:57 +00:00
/* for the uv case, use the same value for both du/dv,
* since individually scaling the normal derivatives makes them useless... */
rename api functions... - minf, maxf, mini, maxi --> min_ff, max_ff, min_ii, max_ii
2012-10-23 13:28:22 +00:00
du = min_ff(du, dv);
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
idu = (du < 1e-5f) ? bf : (bf/du);
style cleanup
2012-07-07 22:51:57 +00:00
/* +u val */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
tco[0] = co[0] + compat_bump->dudnu*du;
tco[1] = co[1] + compat_bump->dvdnu*du;
tco[2] = 0.f;
texco_mapping(shi, tex, mtex, tco, dx, dy, texv, dxt, dyt);
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
multitex_mtex(shi, mtex, texv, dxt, dyt, &ttexr, pool, skip_load_image);
Divide by 3 instead of multiplying by variations of 0.333 Fixes small precision problems.
2013-02-14 17:35:43 +00:00
ud = idu*(cd - (fromrgb ? (ttexr.tr + ttexr.tg + ttexr.tb) / 3.0f : ttexr.tin));
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
style cleanup
2012-07-07 22:51:57 +00:00
/* +v val */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
tco[0] = co[0] + compat_bump->dudnv*du;
tco[1] = co[1] + compat_bump->dvdnv*du;
tco[2] = 0.f;
texco_mapping(shi, tex, mtex, tco, dx, dy, texv, dxt, dyt);
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
multitex_mtex(shi, mtex, texv, dxt, dyt, &ttexr, pool, skip_load_image);
Divide by 3 instead of multiplying by variations of 0.333 Fixes small precision problems.
2013-02-14 17:35:43 +00:00
vd = idu*(cd - (fromrgb ? (ttexr.tr + ttexr.tg + ttexr.tb) / 3.0f : ttexr.tin));
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
}
else {
float tu[3], tv[3];
copy_v3_v3(tu, compat_bump->nu);
copy_v3_v3(tv, compat_bump->nv);
idu = (du < 1e-5f) ? bf : (bf/du);
idv = (dv < 1e-5f) ? bf : (bf/dv);
if ((mtex->texco == TEXCO_ORCO) && shi->obr && shi->obr->ob) {
Bug fix: Render and 3d view conflict over ob->imat * For rendering every object's inverse matrix "ob->imat" needs to be in render view coordinates, but for drawing in 3d view it needs to be in global coordinates. Originally (way back in historical times) ob->imat was only used for rendering, but over the years other uses came up too. Before 2.5 this wasn't a problem as rendering was a totally blocking operation, but with the new "interactive ui while rendering" the problems started. Basically any update that redrew the 3d view while rendering (like rotating the scene with mouse) updated the inverse matrix into global coordinates thus invalidating it for the render, leading to all kinds of strange discontinuities with textures and volumetrics. * Problems were very easy to achieve using orco/object coordinates for pretty much any textures (bump, point density, volume, sky), for examples see bug reports 24906 and 25229. Render baking normals in object coordinates was wrong most of the time too. * Now there is a separate inverse matrix ob->imat_ren that's calculated at the beginning of rendering and is used in all places inside render code where it's needed. This way the original ob->imat can change at will during rendering without causing problems.
2011-02-28 15:42:15 +00:00
mul_mat3_m4_v3(shi->obr->ob->imat_ren, tu);
mul_mat3_m4_v3(shi->obr->ob->imat_ren, tv);
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
normalize_v3(tu);
normalize_v3(tv);
}
else if (mtex->texco == TEXCO_GLOB) {
mul_mat3_m4_v3(R.viewinv, tu);
mul_mat3_m4_v3(R.viewinv, tv);
}
else if (mtex->texco == TEXCO_OBJECT && mtex->object) {
Bug fix: Render and 3d view conflict over ob->imat * For rendering every object's inverse matrix "ob->imat" needs to be in render view coordinates, but for drawing in 3d view it needs to be in global coordinates. Originally (way back in historical times) ob->imat was only used for rendering, but over the years other uses came up too. Before 2.5 this wasn't a problem as rendering was a totally blocking operation, but with the new "interactive ui while rendering" the problems started. Basically any update that redrew the 3d view while rendering (like rotating the scene with mouse) updated the inverse matrix into global coordinates thus invalidating it for the render, leading to all kinds of strange discontinuities with textures and volumetrics. * Problems were very easy to achieve using orco/object coordinates for pretty much any textures (bump, point density, volume, sky), for examples see bug reports 24906 and 25229. Render baking normals in object coordinates was wrong most of the time too. * Now there is a separate inverse matrix ob->imat_ren that's calculated at the beginning of rendering and is used in all places inside render code where it's needed. This way the original ob->imat can change at will during rendering without causing problems.
2011-02-28 15:42:15 +00:00
mul_mat3_m4_v3(mtex->object->imat_ren, tu);
mul_mat3_m4_v3(mtex->object->imat_ren, tv);
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
normalize_v3(tu);
normalize_v3(tv);
}
style cleanup
2012-07-07 22:51:57 +00:00
/* +u val */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
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);
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
multitex_mtex(shi, mtex, texv, dxt, dyt, &ttexr, pool, skip_load_image);
Divide by 3 instead of multiplying by variations of 0.333 Fixes small precision problems.
2013-02-14 17:35:43 +00:00
ud = idu*(cd - (fromrgb ? (ttexr.tr + ttexr.tg + ttexr.tb) / 3.0f : ttexr.tin));
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
style cleanup
2012-07-07 22:51:57 +00:00
/* +v val */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
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);
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
multitex_mtex(shi, mtex, texv, dxt, dyt, &ttexr, pool, skip_load_image);
Divide by 3 instead of multiplying by variations of 0.333 Fixes small precision problems.
2013-02-14 17:35:43 +00:00
vd = idv*(cd - (fromrgb ? (ttexr.tr + ttexr.tg + ttexr.tb) / 3.0f : ttexr.tin));
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
}
style cleanup
2012-07-07 22:51:57 +00:00
/* bumped normal */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
compat_bump->nu[0] += ud*compat_bump->nn[0];
compat_bump->nu[1] += ud*compat_bump->nn[1];
compat_bump->nu[2] += ud*compat_bump->nn[2];
compat_bump->nv[0] += vd*compat_bump->nn[0];
compat_bump->nv[1] += vd*compat_bump->nn[1];
compat_bump->nv[2] += vd*compat_bump->nn[2];
cross_v3_v3v3(nvec, compat_bump->nu, compat_bump->nv);
nvec[0] = -nvec[0];
nvec[1] = -nvec[1];
nvec[2] = -nvec[2];
texres->nor = nvec;
rgbnor |= TEX_NOR;
return rgbnor;
}
/* Improved bump code from later in 2.5 development cycle */
typedef struct NTapBump {
bump-mapping update to properly support multiple textures in different bump-spaces. kudos to M.L.Mikkelsen (sparky) for helping with the math! :)
2011-02-07 21:55:54 +00:00
int init_done;
style cleanup
2012-07-07 22:51:57 +00:00
int iPrevBumpSpace; /* 0: uninitialized, 1: objectspace, 2: texturespace, 4: viewspace */
/* bumpmapping */
float vNorg[3]; /* backup copy of shi->vn */
float vNacc[3]; /* original surface normal minus the surface gradient of every bump map which is encountered */
float vR1[3], vR2[3]; /* cross products (sigma_y, original_normal), (original_normal, sigma_x) */
float sgn_det; /* sign of the determinant of the matrix {sigma_x, sigma_y, original_normal} */
float fPrevMagnitude; /* copy of previous magnitude, used for multiple bumps in different spaces */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
} NTapBump;
static void ntap_bump_init(NTapBump *ntap_bump)
{
memset(ntap_bump, 0, sizeof(*ntap_bump));
}
code cleanup: - define array sizes for functions that take vectors. - quiet some -Wshadow warnings. - some copy/paste error in readfile.c made it set the same particle recalc flag twice.
2012-10-20 08:02:18 +00:00
static int ntap_bump_compute(NTapBump *ntap_bump, ShadeInput *shi, MTex *mtex, Tex *tex, TexResult *texres,
float Tnor, const float co[3], const float dx[3], const float dy[3],
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
float texvec[3], float dxt[3], float dyt[3], struct ImagePool *pool,
const bool skip_load_image)
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
{
style cleanup
2012-07-07 22:51:57 +00:00
TexResult ttexr = {0, 0, 0, 0, 0, texres->talpha, NULL}; /* temp TexResult */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
const int fromrgb = ((tex->type == TEX_IMAGE) || ((tex->flag & TEX_COLORBAND)!=0));
Bump maps flip: now white means salience, black means concavity Files created in blender before this revision should be rendered in exactly the same way they used to render before. Patch by Morten Mikkelsen, finished by Ton and me.
2011-09-30 09:55:21 +00:00
style cleanup
2012-07-07 22:51:57 +00:00
/* The negate on Hscale is done because the
* normal in the renderer points inward which corresponds
* to inverting the bump map. The normals are generated
* this way in calc_vertexnormals(). Should this ever change
* this negate must be removed. */
Bump maps flip: now white means salience, black means concavity Files created in blender before this revision should be rendered in exactly the same way they used to render before. Patch by Morten Mikkelsen, finished by Ton and me.
2011-09-30 09:55:21 +00:00
float Hscale = -Tnor*mtex->norfac;
glsl and render support for derivative maps
2011-08-22 19:57:54 +00:00
int dimx=512, dimy=512;
style cleanup
2012-07-07 22:51:57 +00:00
const int imag_tspace_dimension_x = 1024; /* only used for texture space variant */
addendum to prev bugfix on texture space bump
2011-09-22 05:36:52 +00:00
float aspect = 1.0f;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
style cleanup
2012-07-07 22:51:57 +00:00
/* 2 channels for 2D texture and 3 for 3D textures. */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
const int nr_channels = (mtex->texco == TEXCO_UV)? 2 : 3;
bump-mapping update to properly support multiple textures in different bump-spaces. kudos to M.L.Mikkelsen (sparky) for helping with the math! :)
2011-02-07 21:55:54 +00:00
int c, rgbnor, iBumpSpace;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
float dHdx, dHdy;
glsl and render support for derivative maps
2011-08-22 19:57:54 +00:00
int found_deriv_map = (tex->type==TEX_IMAGE) && (tex->imaflag & TEX_DERIVATIVEMAP);
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
style cleanup
2012-07-07 22:51:57 +00:00
/* disable internal bump eval in sampler, save pointer */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
float *nvec = texres->nor;
texres->nor = NULL;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (found_deriv_map==0) {
if ( mtex->texflag & MTEX_BUMP_TEXTURESPACE ) {
if (tex->ima)
style cleanup
2012-07-07 22:51:57 +00:00
Hscale *= 13.0f; /* appears to be a sensible default value */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
else
style cleanup
2012-07-07 22:51:57 +00:00
Hscale *= 0.1f; /* factor 0.1 proved to look like the previous bump code */
fixes scale on derivative maps
2011-12-09 23:26:06 +00:00
}
bump-mapping update to properly support multiple textures in different bump-spaces. kudos to M.L.Mikkelsen (sparky) for helping with the math! :)
2011-02-07 21:55:54 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ( !ntap_bump->init_done ) {
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(ntap_bump->vNacc, shi->vn);
copy_v3_v3(ntap_bump->vNorg, shi->vn);
bump-mapping update to properly support multiple textures in different bump-spaces. kudos to M.L.Mikkelsen (sparky) for helping with the math! :)
2011-02-07 21:55:54 +00:00
ntap_bump->fPrevMagnitude = 1.0f;
ntap_bump->iPrevBumpSpace = 0;
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
ntap_bump->init_done = true;
bump-mapping update to properly support multiple textures in different bump-spaces. kudos to M.L.Mikkelsen (sparky) for helping with the math! :)
2011-02-07 21:55:54 +00:00
}
glsl and render support for derivative maps
2011-08-22 19:57:54 +00:00
style cleanup
2012-07-07 22:51:57 +00:00
/* resolve image dimensions */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (found_deriv_map || (mtex->texflag&MTEX_BUMP_TEXTURESPACE)!=0) {
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
ImBuf *ibuf = BKE_image_pool_acquire_ibuf(tex->ima, &tex->iuser, pool);
glsl and render support for derivative maps
2011-08-22 19:57:54 +00:00
if (ibuf) {
dimx = ibuf->x;
dimy = ibuf->y;
addendum to prev bugfix on texture space bump
2011-09-22 05:36:52 +00:00
aspect = ((float) dimy) / dimx;
glsl and render support for derivative maps
2011-08-22 19:57:54 +00:00
}
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
BKE_image_pool_release_ibuf(tex->ima, ibuf, pool);
glsl and render support for derivative maps
2011-08-22 19:57:54 +00:00
}
bump-mapping update to properly support multiple textures in different bump-spaces. kudos to M.L.Mikkelsen (sparky) for helping with the math! :)
2011-02-07 21:55:54 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (found_deriv_map) {
verify existence of dm
2011-12-10 01:00:12 +00:00
float dBdu, dBdv, auto_bump = 1.0f;
style cleanup
2012-07-07 22:51:57 +00:00
float s = 1; /* negate this if flipped texture coordinate */
glsl and render support for derivative maps
2011-08-22 19:57:54 +00:00
texco_mapping(shi, tex, mtex, co, dx, dy, texvec, dxt, dyt);
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
rgbnor = multitex_mtex(shi, mtex, texvec, dxt, dyt, texres, pool, skip_load_image);
fixes scale on derivative maps
2011-12-09 23:26:06 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->obr->ob->derivedFinal) {
verify existence of dm
2011-12-10 01:00:12 +00:00
auto_bump = shi->obr->ob->derivedFinal->auto_bump_scale;
}
style cleanup, brackets in else/if, some indentation.
2012-03-06 18:40:15 +00:00
svn merge ^/trunk/blender -r43092:43092
2012-01-04 06:20:10 +00:00
{
float fVirtDim = sqrtf(fabsf((float) (dimx*dimy)*mtex->size[0]*mtex->size[1]));
auto_bump /= MAX2(fVirtDim, FLT_EPSILON);
}
style cleanup
2012-07-07 22:51:57 +00:00
/* this variant using a derivative map is described here
* http://mmikkelsen3d.blogspot.com/2011/07/derivative-maps.html */
fixes scale on derivative maps
2011-12-09 23:26:06 +00:00
dBdu = auto_bump*Hscale*dimx*(2*texres->tr-1);
dBdv = auto_bump*Hscale*dimy*(2*texres->tg-1);
glsl and render support for derivative maps
2011-08-22 19:57:54 +00:00
dHdx = dBdu*dxt[0] + s * dBdv*dxt[1];
dHdy = dBdu*dyt[0] + s * dBdv*dyt[1];
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (!(mtex->texflag & MTEX_5TAP_BUMP)) {
style cleanup
2012-07-07 22:51:57 +00:00
/* compute height derivatives with respect to output image pixel coordinates x and y */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
float STll[3], STlr[3], STul[3];
float Hll, Hlr, Hul;
texco_mapping(shi, tex, mtex, co, dx, dy, texvec, dxt, dyt);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
for (c=0; c<nr_channels; c++) {
style cleanup
2012-07-07 22:51:57 +00:00
/* dx contains the derivatives (du/dx, dv/dx)
* dy contains the derivatives (du/dy, dv/dy) */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
STll[c] = texvec[c];
STlr[c] = texvec[c]+dxt[c];
STul[c] = texvec[c]+dyt[c];
}
style cleanup
2012-07-07 22:51:57 +00:00
/* clear unused derivatives */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
for (c=nr_channels; c<3; c++) {
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
STll[c] = 0.0f;
STlr[c] = 0.0f;
STul[c] = 0.0f;
}
style cleanup
2012-07-07 22:51:57 +00:00
/* use texres for the center sample, set rgbnor */
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
rgbnor = multitex_mtex(shi, mtex, STll, dxt, dyt, texres, pool, skip_load_image);
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
Hll = (fromrgb) ? rgb_to_grayscale(&texres->tr) : texres->tin;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
style cleanup
2012-07-07 22:51:57 +00:00
/* use ttexr for the other 2 taps */
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
multitex_mtex(shi, mtex, STlr, dxt, dyt, &ttexr, pool, skip_load_image);
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
Hlr = (fromrgb) ? rgb_to_grayscale(&ttexr.tr) : ttexr.tin;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
multitex_mtex(shi, mtex, STul, dxt, dyt, &ttexr, pool, skip_load_image);
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
Hul = (fromrgb) ? rgb_to_grayscale(&ttexr.tr) : ttexr.tin;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
dHdx = Hscale*(Hlr - Hll);
dHdy = Hscale*(Hul - Hll);
}
else {
/* same as above, but doing 5 taps, increasing quality at cost of speed */
float STc[3], STl[3], STr[3], STd[3], STu[3];
tag & comment unused vars with /* UNUSED */
2011-09-20 08:48:48 +00:00
float /* Hc, */ /* UNUSED */ Hl, Hr, Hd, Hu;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
texco_mapping(shi, tex, mtex, co, dx, dy, texvec, dxt, dyt);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
for (c=0; c<nr_channels; c++) {
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
STc[c] = texvec[c];
STl[c] = texvec[c] - 0.5f*dxt[c];
STr[c] = texvec[c] + 0.5f*dxt[c];
STd[c] = texvec[c] - 0.5f*dyt[c];
STu[c] = texvec[c] + 0.5f*dyt[c];
}
style cleanup
2012-07-07 22:51:57 +00:00
/* clear unused derivatives */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
for (c=nr_channels; c<3; c++) {
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
STc[c] = 0.0f;
STl[c] = 0.0f;
STr[c] = 0.0f;
STd[c] = 0.0f;
STu[c] = 0.0f;
}
style cleanup
2012-07-07 22:51:57 +00:00
/* use texres for the center sample, set rgbnor */
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
rgbnor = multitex_mtex(shi, mtex, STc, dxt, dyt, texres, pool, skip_load_image);
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
/* Hc = (fromrgb) ? rgb_to_grayscale(&texres->tr) : texres->tin; */ /* UNUSED */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
style cleanup
2012-07-07 22:51:57 +00:00
/* use ttexr for the other taps */
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
multitex_mtex(shi, mtex, STl, dxt, dyt, &ttexr, pool, skip_load_image);
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
Hl = (fromrgb) ? rgb_to_grayscale(&ttexr.tr) : ttexr.tin;
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
multitex_mtex(shi, mtex, STr, dxt, dyt, &ttexr, pool, skip_load_image);
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
Hr = (fromrgb) ? rgb_to_grayscale(&ttexr.tr) : ttexr.tin;
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
multitex_mtex(shi, mtex, STd, dxt, dyt, &ttexr, pool, skip_load_image);
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
Hd = (fromrgb) ? rgb_to_grayscale(&ttexr.tr) : ttexr.tin;
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
multitex_mtex(shi, mtex, STu, dxt, dyt, &ttexr, pool, skip_load_image);
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
Hu = (fromrgb) ? rgb_to_grayscale(&ttexr.tr) : ttexr.tin;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
dHdx = Hscale*(Hr - Hl);
dHdy = Hscale*(Hu - Hd);
}
style cleanup
2012-07-07 22:51:57 +00:00
/* restore pointer */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
texres->nor = nvec;
/* replaced newbump with code based on listing 1 and 2 of
code cleanup: spelling
2012-05-20 21:23:26 +00:00
* [Mik10] Mikkelsen M. S.: Bump Mapping Unparameterized Surfaces on the GPU.
style cleanup: comment blocks
2012-03-09 18:28:30 +00:00
* -> http://jbit.net/~sparky/sfgrad_bump/mm_sfgrad_bump.pdf */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ( mtex->texflag & MTEX_BUMP_OBJECTSPACE )
bump-mapping update to properly support multiple textures in different bump-spaces. kudos to M.L.Mikkelsen (sparky) for helping with the math! :)
2011-02-07 21:55:54 +00:00
iBumpSpace = 1;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if ( mtex->texflag & MTEX_BUMP_TEXTURESPACE )
bump-mapping update to properly support multiple textures in different bump-spaces. kudos to M.L.Mikkelsen (sparky) for helping with the math! :)
2011-02-07 21:55:54 +00:00
iBumpSpace = 2;
else
style cleanup
2012-07-07 22:51:57 +00:00
iBumpSpace = 4; /* ViewSpace */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ( ntap_bump->iPrevBumpSpace != iBumpSpace ) {
style cleanup
2012-07-07 22:51:57 +00:00
/* initialize normal perturbation vectors */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
int xyz;
bump-mapping update to properly support multiple textures in different bump-spaces. kudos to M.L.Mikkelsen (sparky) for helping with the math! :)
2011-02-07 21:55:54 +00:00
float fDet, abs_fDet, fMagnitude;
style cleanup
2012-07-07 22:51:57 +00:00
/* object2view and inverted matrix */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
float obj2view[3][3], view2obj[3][3], tmp[4][4];
style cleanup
2012-07-07 22:51:57 +00:00
/* local copies of derivatives and normal */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
float dPdx[3], dPdy[3], vN[3];
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(dPdx, shi->dxco);
copy_v3_v3(dPdy, shi->dyco);
copy_v3_v3(vN, ntap_bump->vNorg);
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ( mtex->texflag & MTEX_BUMP_OBJECTSPACE ) {
style cleanup
2012-07-07 22:51:57 +00:00
/* TODO: these calculations happen for every pixel!
* -> move to shi->obi */
BLI_math rename functions: - mult_m4_m4m4 -> mul_m4_m4m4 - mult_m3_m3m4 -> mul_m3_m3m4 these temporary names were used to avoid problems when argument order was switched.
2013-05-26 18:36:25 +00:00
mul_m4_m4m4(tmp, R.viewmat, shi->obr->ob->obmat);
style cleanup
2012-07-07 22:51:57 +00:00
copy_m3_m4(obj2view, tmp); /* use only upper left 3x3 matrix */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
invert_m3_m3(view2obj, obj2view);
style cleanup
2012-07-07 22:51:57 +00:00
/* generate the surface derivatives in object space */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
mul_m3_v3(view2obj, dPdx);
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
mul_m3_v3(view2obj, dPdy);
style cleanup
2012-07-07 22:51:57 +00:00
/* generate the unit normal in object space */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
mul_transposed_m3_v3(obj2view, vN);
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
normalize_v3(vN);
}
cross_v3_v3v3(ntap_bump->vR1, dPdy, vN);
cross_v3_v3v3(ntap_bump->vR2, vN, dPdx);
fDet = dot_v3v3(dPdx, ntap_bump->vR1);
ntap_bump->sgn_det = (fDet < 0)? -1.0f: 1.0f;
abs_fDet = ntap_bump->sgn_det * fDet;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ( mtex->texflag & MTEX_BUMP_TEXTURESPACE ) {
if (tex->ima) {
style cleanup
2012-07-07 22:51:57 +00:00
/* crazy hack solution that gives results similar to normal mapping - part 1 */
Bugfix #25855 New bump code: option "Texture space" only works for image textures. It appears this option is some kind of "fake normal map" actually. Needs nicer name... maybe "Image space". Now it ignores the option when no image texture is used.
2011-01-30 14:19:12 +00:00
normalize_v3(ntap_bump->vR1);
normalize_v3(ntap_bump->vR2);
abs_fDet = 1.0f;
}
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
}
bump-mapping update to properly support multiple textures in different bump-spaces. kudos to M.L.Mikkelsen (sparky) for helping with the math! :)
2011-02-07 21:55:54 +00:00
fMagnitude = abs_fDet;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ( mtex->texflag & MTEX_BUMP_OBJECTSPACE ) {
style cleanup
2012-07-07 22:51:57 +00:00
/* pre do transform of texres->nor by the inverse transposed of obj2view */
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
mul_transposed_m3_v3(view2obj, vN);
mul_transposed_m3_v3(view2obj, ntap_bump->vR1);
mul_transposed_m3_v3(view2obj, ntap_bump->vR2);
bump-mapping update to properly support multiple textures in different bump-spaces. kudos to M.L.Mikkelsen (sparky) for helping with the math! :)
2011-02-07 21:55:54 +00:00
fMagnitude *= len_v3(vN);
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
}
bump-mapping update to properly support multiple textures in different bump-spaces. kudos to M.L.Mikkelsen (sparky) for helping with the math! :)
2011-02-07 21:55:54 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (ntap_bump->fPrevMagnitude > 0.0f)
for (xyz=0; xyz<3; xyz++)
bump-mapping update to properly support multiple textures in different bump-spaces. kudos to M.L.Mikkelsen (sparky) for helping with the math! :)
2011-02-07 21:55:54 +00:00
ntap_bump->vNacc[xyz] *= fMagnitude / ntap_bump->fPrevMagnitude;
ntap_bump->fPrevMagnitude = fMagnitude;
ntap_bump->iPrevBumpSpace = iBumpSpace;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ( mtex->texflag & MTEX_BUMP_TEXTURESPACE ) {
if (tex->ima) {
style cleanup
2012-07-07 22:51:57 +00:00
/* crazy hack solution that gives results similar to normal mapping - part 2 */
glsl and render support for derivative maps
2011-08-22 19:57:54 +00:00
float vec[2];
addendum to prev bugfix on texture space bump
2011-09-22 05:36:52 +00:00
const float imag_tspace_dimension_y = aspect*imag_tspace_dimension_x;
Bugfix #25855 New bump code: option "Texture space" only works for image textures. It appears this option is some kind of "fake normal map" actually. Needs nicer name... maybe "Image space". Now it ignores the option when no image texture is used.
2011-01-30 14:19:12 +00:00
addendum to prev bugfix on texture space bump
2011-09-22 05:36:52 +00:00
vec[0] = imag_tspace_dimension_x*dxt[0];
vec[1] = imag_tspace_dimension_y*dxt[1];
Bugfix #25855 New bump code: option "Texture space" only works for image textures. It appears this option is some kind of "fake normal map" actually. Needs nicer name... maybe "Image space". Now it ignores the option when no image texture is used.
2011-01-30 14:19:12 +00:00
dHdx *= 1.0f/len_v2(vec);
addendum to prev bugfix on texture space bump
2011-09-22 05:36:52 +00:00
vec[0] = imag_tspace_dimension_x*dyt[0];
vec[1] = imag_tspace_dimension_y*dyt[1];
Bugfix #25855 New bump code: option "Texture space" only works for image textures. It appears this option is some kind of "fake normal map" actually. Needs nicer name... maybe "Image space". Now it ignores the option when no image texture is used.
2011-01-30 14:19:12 +00:00
dHdy *= 1.0f/len_v2(vec);
}
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
}
style cleanup
2012-07-07 22:51:57 +00:00
/* subtract the surface gradient from vNacc */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
for (c=0; c<3; c++) {
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
float vSurfGrad_compi = ntap_bump->sgn_det * (dHdx * ntap_bump->vR1[c] + dHdy * ntap_bump->vR2[c]);
ntap_bump->vNacc[c] -= vSurfGrad_compi;
style cleanup
2012-07-07 22:51:57 +00:00
texres->nor[c] = ntap_bump->vNacc[c]; /* copy */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
}
rgbnor |= TEX_NOR;
return rgbnor;
}
Dynamic Paint: * Redesigned alpha blending and paint drying algorithms. Now it gives much better results when using low brush alpha or when surface has initial color set. * Fix: "Slow" dissolve/dry was scaled incorrect when using substeps. Also adjusted time to better match non-"slow" setting. * Fixed possible issues when using image textured brush. * Fix: particle brush panel was no longer visible since last commit. * Adjusted default surface values. * Some more code cleanup.
2011-10-31 13:01:06 +00:00
void do_material_tex(ShadeInput *shi, 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
{
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
const bool skip_load_image = (R.r.scemode & R_NO_IMAGE_LOAD) != 0;
Bugfix #25953 Fix in crashing displacement last friday, assumed wrongly that the old 'new bump' failed for displacement too. It still did work (somewhat). This restores the situation again.
2011-02-06 18:38:53 +00:00
CompatibleBump compat_bump;
NTapBump ntap_bump;
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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;
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;
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
int tex_nr, rgbnor= 0;
bool warp_done = false, use_compat_bump = false, use_ntap_bump = false;
bool found_nmapping = false, found_deriv_map = false;
bool iFirstTimeNMap = true;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
compatible_bump_init(&compat_bump);
ntap_bump_init(&ntap_bump);
Revert bump mapping patch for now, backwards compatibility is not good enough, we may need to preserve the previous method.
2011-01-07 16:55:56 +00:00
Dynamic Paint: * Redesigned alpha blending and paint drying algorithms. Now it gives much better results when using low brush alpha or when surface has initial color set. * Fix: "Slow" dissolve/dry was scaled incorrect when using substeps. Also adjusted time to better match non-"slow" setting. * Fixed possible issues when using image textured brush. * Fix: particle brush panel was no longer visible since last commit. * Adjusted default surface values. * Some more code cleanup.
2011-10-31 13:01:06 +00:00
if (re->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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->mat->septex & (1<<tex_nr)) continue;
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have to do it themselves. This commit will need quite some testing help, but I'm around!
2003-12-21 21:52:51 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->mat->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
mtex= shi->mat->mtex[tex_nr];
tex= mtex->tex;
code cleanup: use NULL rather then zero for pointers
2013-08-07 03:30:23 +00:00
if (tex == NULL) 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
glsl and render support for derivative maps
2011-08-22 19:57:54 +00:00
found_deriv_map = (tex->type==TEX_IMAGE) && (tex->imaflag & TEX_DERIVATIVEMAP);
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
use_compat_bump= (mtex->texflag & MTEX_COMPAT_BUMP) != 0;
use_ntap_bump = ((mtex->texflag & (MTEX_3TAP_BUMP|MTEX_5TAP_BUMP|MTEX_BICUBIC_BUMP))!=0 || found_deriv_map!=0) ? true : false;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
Bugfix #20027 Texture Nodes didn't work for normal output anymore anymore. It was caused by new handling of bump code using derivatives, but that's not how texture nodes work now. In case a texture has nodes, it uses the old (2.4) method.
2010-11-11 16:50:04 +00:00
/* XXX texture node trees don't work for this yet */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->nodetree && tex->use_nodes) {
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
use_compat_bump = false;
use_ntap_bump = false;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
}
Bugfix #25953 Fix in crashing displacement last friday, assumed wrongly that the old 'new bump' failed for displacement too. It still did work (somewhat). This restores the situation again.
2011-02-06 18:38:53 +00:00
/* case displacement mapping */
code cleanup: use TRUE/FALSE rather then 1/0 for better readability, also replace do prefix with do_ for bool vars.
2012-05-19 13:28:19 +00:00
if (shi->osatex == 0 && use_ntap_bump) {
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
use_ntap_bump = false;
use_compat_bump = true;
Bugfix #25953 Fix in crashing displacement last friday, assumed wrongly that the old 'new bump' failed for displacement too. It still did work (somewhat). This restores the situation again.
2011-02-06 18:38:53 +00:00
}
Ocean Sim modifier patch by Matt Ebb, Hamed Zaghaghi This adds a new Modifier "Ocean" to simulate large-scale wave motion. Details can be found in the wiki documentation [1], the project homepage [2] and the patch tracker [3] The modifier is disabled by default for now. To enable it, the WITH_OCEANSIM (cmake) / WITH_BF_OCEANSIM (scons) flags have to be set. The code depends on fftw3, so this also has to be enabled. [1] http://wiki.blender.org/index.php/Doc:2.6/Manual/Modifiers/Simulation/Ocean [2] http://www.savetheoceansim.com [3] http://projects.blender.org/tracker/?group_id=9&atid=127&func=detail&aid=28338
2011-11-13 12:17:27 +00:00
/* case ocean */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->type == TEX_OCEAN) {
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
use_ntap_bump = false;
use_compat_bump = false;
Ocean Sim modifier patch by Matt Ebb, Hamed Zaghaghi This adds a new Modifier "Ocean" to simulate large-scale wave motion. Details can be found in the wiki documentation [1], the project homepage [2] and the patch tracker [3] The modifier is disabled by default for now. To enable it, the WITH_OCEANSIM (cmake) / WITH_BF_OCEANSIM (scons) flags have to be set. The code depends on fftw3, so this also has to be enabled. [1] http://wiki.blender.org/index.php/Doc:2.6/Manual/Modifiers/Simulation/Ocean [2] http://www.savetheoceansim.com [3] http://projects.blender.org/tracker/?group_id=9&atid=127&func=detail&aid=28338
2011-11-13 12:17:27 +00:00
}
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texco==TEXCO_ORCO) {
if (mtex->texflag & MTEX_DUPLI_MAPTO) {
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= shi->duplilo; dx= dxt; dy= dyt;
dxt[0]= dxt[1]= dxt[2]= 0.0f;
dyt[0]= dyt[1]= dyt[2]= 0.0f;
}
else {
Revert bump mapping patch for now, backwards compatibility is not good enough, we may need to preserve the previous method.
2011-01-07 16:55:56 +00:00
co= shi->lo; dx= shi->dxlo; dy= shi->dylo;
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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (ob) {
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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;
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(tempvec, shi->co);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texflag & MTEX_OB_DUPLI_ORIG)
if (shi->obi && shi->obi->duplitexmat)
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
mul_m4_v3(shi->obi->duplitexmat, tempvec);
Bug fix: Render and 3d view conflict over ob->imat * For rendering every object's inverse matrix "ob->imat" needs to be in render view coordinates, but for drawing in 3d view it needs to be in global coordinates. Originally (way back in historical times) ob->imat was only used for rendering, but over the years other uses came up too. Before 2.5 this wasn't a problem as rendering was a totally blocking operation, but with the new "interactive ui while rendering" the problems started. Basically any update that redrew the 3d view while rendering (like rotating the scene with mouse) updated the inverse matrix into global coordinates thus invalidating it for the render, leading to all kinds of strange discontinuities with textures and volumetrics. * Problems were very easy to achieve using orco/object coordinates for pretty much any textures (bump, point density, volume, sky), for examples see bug reports 24906 and 25229. Render baking normals in object coordinates was wrong most of the time too. * Now there is a separate inverse matrix ob->imat_ren that's calculated at the beginning of rendering and is used in all places inside render code where it's needed. This way the original ob->imat can change at will during rendering without causing problems.
2011-02-28 15:42:15 +00:00
mul_m4_v3(ob->imat_ren, tempvec);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->osatex) {
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(dxt, shi->dxco);
copy_v3_v3(dyt, shi->dyco);
Bug fix: Render and 3d view conflict over ob->imat * For rendering every object's inverse matrix "ob->imat" needs to be in render view coordinates, but for drawing in 3d view it needs to be in global coordinates. Originally (way back in historical times) ob->imat was only used for rendering, but over the years other uses came up too. Before 2.5 this wasn't a problem as rendering was a totally blocking operation, but with the new "interactive ui while rendering" the problems started. Basically any update that redrew the 3d view while rendering (like rotating the scene with mouse) updated the inverse matrix into global coordinates thus invalidating it for the render, leading to all kinds of strange discontinuities with textures and volumetrics. * Problems were very easy to achieve using orco/object coordinates for pretty much any textures (bump, point density, volume, sky), for examples see bug reports 24906 and 25229. Render baking normals in object coordinates was wrong most of the time too. * Now there is a separate inverse matrix ob->imat_ren that's calculated at the beginning of rendering and is used in all places inside render code where it's needed. This way the original ob->imat can change at will during rendering without causing problems.
2011-02-28 15:42:15 +00:00
mul_mat3_m4_v3(ob->imat_ren, dxt);
mul_mat3_m4_v3(ob->imat_ren, 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
}
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->texco==TEXCO_REFL) {
Fix #27540: bug with bump mapping + reflection texture coordinates + nodes.
2011-06-13 14:56:47 +00:00
calc_R_ref(shi);
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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->texco==TEXCO_TANGENT) {
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
co= shi->tang; dx= shi->dxno; dy= shi->dyno;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->texco==TEXCO_GLOB) {
Fix #22964: incorrect derivatives for global texture coordinates, showed up as artifacts in bump mapping.
2010-07-28 11:10:56 +00:00
co= shi->gl; dx= shi->dxgl; dy= shi->dygl;
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have to do it themselves. This commit will need quite some testing help, but I'm around!
2003-12-21 21:52:51 +00:00
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->texco==TEXCO_UV) {
if (mtex->texflag & MTEX_DUPLI_MAPTO) {
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= 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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->uvname[0] != 0) {
for (i = 0; i < shi->totuv; i++) {
Cleanup: strcmp/strncmp -> STREQ/STREQLEN (in boolean usage). Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)' and 'strcmp(foo, bar) == 0' in several places...
2015-01-26 16:03:11 +01:00
if (STREQ(shi->uv[i].name, mtex->uvname)) {
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
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;
Revert bump mapping patch for now, backwards compatibility is not good enough, we may need to preserve the previous method.
2011-01-07 16:55:56 +00:00
dy= suv->dyuv;
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
compatible_bump_uv_derivs(&compat_bump, shi, mtex, i);
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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->texco==TEXCO_STRAND) {
- 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= 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;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->texco==TEXCO_STRESS) {
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
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;
}
style cleanup
2012-07-07 22:51:57 +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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & (MAP_NORM|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
code cleanup: use TRUE/FALSE rather then 1/0 for better readability, also replace do prefix with do_ for bool vars.
2012-05-19 13:28:19 +00:00
if (warp_done) {
replace macros with math functions for render code
2011-11-06 14:36:37 +00:00
add_v3_v3v3(tempvec, co, warpvec);
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
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
Bugfix #20027 Texture Nodes didn't work for normal output anymore anymore. It was caused by new handling of bump code using derivatives, but that's not how texture nodes work now. In case a texture has nodes, it uses the old (2.4) method.
2010-11-11 16:50:04 +00:00
/* XXX texture node trees don't work for this yet */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (texres.nor && !((tex->type==TEX_IMAGE) && (tex->imaflag & TEX_NORMALMAP))) {
if (use_compat_bump) {
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
rgbnor = compatible_bump_compute(&compat_bump, shi, mtex, tex,
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
&texres, Tnor*stencilTin, co, dx, dy, texvec, dxt, dyt,
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
re->pool, skip_load_image);
converted more mixed tab/space indentations to tabs. only whitespace changes.
2011-04-21 15:53:30 +00:00
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (use_ntap_bump) {
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
rgbnor = ntap_bump_compute(&ntap_bump, shi, mtex, tex,
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
&texres, Tnor*stencilTin, co, dx, dy, texvec, dxt, dyt,
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
re->pool, skip_load_image);
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);
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
rgbnor = multitex_mtex(shi, mtex, texvec, dxt, dyt, &texres, re->pool, skip_load_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
}
}
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);
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
rgbnor = multitex_mtex(shi, mtex, texvec, dxt, dyt, &texres, re->pool, skip_load_image);
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
}
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 */
Revert bump mapping patch for now, backwards compatibility is not good enough, we may need to preserve the previous method.
2011-01-07 16:55:56 +00:00
Code cleanup: style
2014-03-17 21:48:13 +11:00
if ((rgbnor & TEX_RGB) && (mtex->texflag & MTEX_RGBTOINT)) {
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
texres.tin = rgb_to_grayscale(&texres.tr);
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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texflag & MTEX_NEGATIVE) {
if (rgbnor & TEX_RGB) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
texres.tr= 1.0f-texres.tr;
texres.tg= 1.0f-texres.tg;
texres.tb= 1.0f-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
}
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
texres.tin= 1.0f-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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (texres.nor) {
if ((rgbnor & TEX_NOR)==0) {
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
/* make our own normal */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (rgbnor & TEX_RGB) {
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
copy_v3_v3(texres.nor, &texres.tr);
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 {
Cleanup: use float versions of functions when in/output are floats
2014-09-17 14:11:37 +10:00
float co_nor= 0.5f * cosf(texres.tin - 0.5f);
float si = 0.5f * sinf(texres.tin - 0.5f);
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;
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
}
style cleanup
2012-07-07 22:51:57 +00:00
/* warping, local space */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & MAP_WARP) {
Bugfix 26578 "Warp" texture map option didnt work for new bump methods yet. Also fixed to not grey out bump menu for this mapping option.
2011-03-24 18:39:54 +00:00
float *warpnor= texres.nor, warpnor_[3];
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (use_ntap_bump) {
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(warpnor_, texres.nor);
Bugfix 26578 "Warp" texture map option didnt work for new bump methods yet. Also fixed to not grey out bump menu for this mapping option.
2011-03-24 18:39:54 +00:00
warpnor= warpnor_;
normalize_v3(warpnor_);
}
warpvec[0]= mtex->warpfac*warpnor[0];
warpvec[1]= mtex->warpfac*warpnor[1];
warpvec[2]= mtex->warpfac*warpnor[2];
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
warp_done = true;
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
}
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texflag & MTEX_VIEWSPACE) {
style cleanup
2012-07-07 22:51:57 +00:00
/* rotate to global coords */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texco==TEXCO_ORCO || mtex->texco==TEXCO_UV) {
if (shi->vlr && shi->obr && shi->obr->ob) {
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
float len= normalize_v3(texres.nor);
style cleanup
2012-07-07 22:51:57 +00:00
/* can be optimized... (ton) */
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
mul_mat3_m4_v3(shi->obr->ob->obmat, texres.nor);
Dynamic Paint: * Redesigned alpha blending and paint drying algorithms. Now it gives much better results when using low brush alpha or when surface has initial color set. * Fix: "Slow" dissolve/dry was scaled incorrect when using substeps. Also adjusted time to better match non-"slow" setting. * Fixed possible issues when using image textured brush. * Fix: particle brush panel was no longer visible since last commit. * Adjusted default surface values. * Some more code cleanup.
2011-10-31 13:01:06 +00:00
mul_mat3_m4_v3(re->viewmat, texres.nor);
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
normalize_v3(texres.nor);
mul_v3_fl(texres.nor, len);
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
}
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
}
style cleanup: whitespace/indentation
2012-05-19 13:55:54 +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 */
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
if (mtex->mapto & (MAP_COL | MAP_COLSPEC | MAP_COLMIR)) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float tcol[3];
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 */
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
copy_v3_v3(tcol, &texres.tr);
if ((rgbnor & TEX_RGB) == 0) {
copy_v3_v3(tcol, &mtex->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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->mapto & MAP_ALPHA) {
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
texres.tin = stencilTin;
}
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
}
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 */
Changes to Color Management After testing and feedback, I've decided to slightly modify the way color management works internally. While the previous method worked well for rendering, was a smaller transition and had some advantages over this new method, it was a bit more ambiguous, and was making things difficult for other areas such as compositing. This implementation now considers all color data (with only a couple of exceptions such as brush colors) to be stored in linear RGB color space, rather than sRGB as previously. This brings it in line with Nuke, which also operates this way, quite successfully. Color swatches, pickers, color ramp display are now gamma corrected to display gamma so you can see what you're doing, but the numbers themselves are considered linear. This makes understanding blending modes more clear (a 0.5 value on overlay will not change the result now) as well as making color swatches act more predictably in the compositor, however bringing over color values from applications like photoshop or gimp, that operate in a gamma space, will give identical results. This commit will convert over existing files saved by earlier 2.5 versions to work generally the same, though there may be some slight differences with things like textures. Now that we're set on changing other areas of shading, this won't be too disruptive overall. I've made a diagram explaining the pipeline here: http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png and some docs here: http://www.blender.org/development/release-logs/blender-250/color-management/
2009-12-02 07:56:34 +00:00
if (tex->type==TEX_IMAGE) {
Image *ima = tex->ima;
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
ImBuf *ibuf = BKE_image_pool_acquire_ibuf(ima, &tex->iuser, re->pool);
Changes to Color Management After testing and feedback, I've decided to slightly modify the way color management works internally. While the previous method worked well for rendering, was a smaller transition and had some advantages over this new method, it was a bit more ambiguous, and was making things difficult for other areas such as compositing. This implementation now considers all color data (with only a couple of exceptions such as brush colors) to be stored in linear RGB color space, rather than sRGB as previously. This brings it in line with Nuke, which also operates this way, quite successfully. Color swatches, pickers, color ramp display are now gamma corrected to display gamma so you can see what you're doing, but the numbers themselves are considered linear. This makes understanding blending modes more clear (a 0.5 value on overlay will not change the result now) as well as making color swatches act more predictably in the compositor, however bringing over color values from applications like photoshop or gimp, that operate in a gamma space, will give identical results. This commit will convert over existing files saved by earlier 2.5 versions to work generally the same, though there may be some slight differences with things like textures. Now that we're set on changing other areas of shading, this won't be too disruptive overall. I've made a diagram explaining the pipeline here: http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png and some docs here: http://www.blender.org/development/release-logs/blender-250/color-management/
2009-12-02 07:56:34 +00:00
/* don't linearize float buffers, assumed to be linear */
Color Management: fixed color management-less texture rendering There was a missing check for whether color management enabled or not when converting byte textures to linear space. This commit also fixes wrong texture preview rendering, which was applying sRGB transform twice, making procedural textures bright. This will make float textures being previewed dark (in a linear space) but that's how it used to behave in pre-OCIO color management.
2012-10-10 05:56:49 +00:00
if (ibuf && !(ibuf->rect_float) && R.scene_color_manage)
Color Management, Stage 2: Switch color pipeline to use OpenColorIO Replace old color pipeline which was supporting linear/sRGB color spaces only with OpenColorIO-based pipeline. This introduces two configurable color spaces: - Input color space for images and movie clips. This space is used to convert images/movies from color space in which file is saved to Blender's linear space (for float images, byte images are not internally converted, only input space is stored for such images and used later). This setting could be found in image/clip data block settings. - Display color space which defines space in which particular display is working. This settings could be found in scene's Color Management panel. When render result is being displayed on the screen, apart from converting image to display space, some additional conversions could happen. This conversions are: - View, which defines tone curve applying before display transformation. These are different ways to view the image on the same display device. For example it could be used to emulate film view on sRGB display. - Exposure affects on image exposure before tone map is applied. - Gamma is post-display gamma correction, could be used to match particular display gamma. - RGB curves are user-defined curves which are applying before display transformation, could be used for different purposes. All this settings by default are only applying on render result and does not affect on other images. If some particular image needs to be affected by this transformation, "View as Render" setting of image data block should be set to truth. Movie clips are always affected by all display transformations. This commit also introduces configurable color space in which sequencer is working. This setting could be found in scene's Color Management panel and it should be used if such stuff as grading needs to be done in color space different from sRGB (i.e. when Film view on sRGB display is use, using VD16 space as sequencer's internal space would make grading working in space which is close to the space using for display). Some technical notes: - Image buffer's float buffer is now always in linear space, even if it was created from 16bit byte images. - Space of byte buffer is stored in image buffer's rect_colorspace property. - Profile of image buffer was removed since it's not longer meaningful. - OpenGL and GLSL is supposed to always work in sRGB space. It is possible to support other spaces, but it's quite large project which isn't so much important. - Legacy Color Management option disabled is emulated by using None display. It could have some regressions, but there's no clear way to avoid them. - If OpenColorIO is disabled on build time, it should make blender behaving in the same way as previous release with color management enabled. More details could be found at this page (more details would be added soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management -- Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO integration and to Brecht van Lommel for some further development and code/ usecase review!
2012-09-15 10:05:07 +00:00
IMB_colormanagement_colorspace_to_scene_linear_v3(tcol, ibuf->rect_colorspace);
Image thread safe improvements This commit makes BKE_image_acquire_ibuf referencing result, which means once some area requested for image buffer, it'll be guaranteed this buffer wouldn't be freed by image signal. To de-reference buffer BKE_image_release_ibuf should now always be used. To make referencing working correct we can not rely on result of image_get_ibuf_threadsafe called outside from thread lock. This is so because we need to guarantee getting image buffer from list of loaded buffers and it's referencing happens atomic. Without lock here it is possible that between call of image_get_ibuf_threadsafe and referencing the buffer IMA_SIGNAL_FREE would be called. Image signal handling too is blocking now to prevent such a situation. Threads are locking by spinlock, which are faster than mutexes. There were some slowdown reports in the past about render slowdown when using OSX on Xeon CPU. It shouldn't happen with spin locks, but more tests on different hardware would be really welcome. So far can not see speed regressions on own computers. This commit also removes BKE_image_get_ibuf, because it was not so intuitive when get_ibuf and acquire_ibuf should be used. Thanks to Ton and Brecht for discussion/review :)
2012-11-15 15:59:58 +00:00
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
BKE_image_pool_release_ibuf(ima, ibuf, re->pool);
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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & MAP_COL) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float colfac= mtex->colfac*stencilTin;
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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & MAP_COLSPEC) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float colspecfac= mtex->colspecfac*stencilTin;
texture_rgb_blend(&shi->specr, tcol, &shi->specr, texres.tin, colspecfac, 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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & MAP_COLMIR) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float mirrfac= mtex->mirrfac*stencilTin;
style cleanup
2012-07-07 22:51:57 +00:00
/* exception for envmap only */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->type==TEX_ENVMAP && mtex->blendtype==MTEX_BLEND) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
fact= texres.tin*mirrfac;
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
facm= 1.0f- 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
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 {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
texture_rgb_blend(&shi->mirr, tcol, &shi->mirr, texres.tin, mirrfac, 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
}
}
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ( (mtex->mapto & MAP_NORM) ) {
if (texres.nor) {
Fix #21227, #21346 and #21336: image texture wasn't centered correctly when sculpting and using it from material nodes.
2010-03-01 18:11:09 +00:00
float norfac= mtex->norfac;
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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: 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)) {
small fix, This enables correction of the tangent when normal mapping is in use and tangent lighting will be used
2011-06-20 03:37:41 +00:00
found_nmapping = 1;
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: for normalmaps, to invert the normalmap vector,
style cleanup: comment blocks
2012-03-09 18:28:30 +00:00
* it is better to negate x & y instead of subtracting the vector as was done before */
Fix #21227, #21346 and #21336: image texture wasn't centered correctly when sculpting and using it from material nodes.
2010-03-01 18:11:09 +00:00
if (norfac < 0.0f) {
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
texres.nor[0] = -texres.nor[0];
texres.nor[1] = -texres.nor[1];
}
quiet -Wdouble-promotion warnings
2011-11-11 12:00:08 +00:00
fact = Tnor*fabsf(norfac);
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 (fact>1.f) fact = 1.f;
facm = 1.f-fact;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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];
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
const float *no = iFirstTimeNMap ? shi->nmapnorm : shi->vn;
iFirstTimeNMap = false;
This commit will switch blender to use tangent space generated within the two files mikktspace.h and mikktspace.c. These are standalone files which can be redistributed into any other application and regenerate the same tangent spaces. The implementation is independent of the ordering of faces and the vertex ordering of faces.
2011-02-14 18:18:46 +00:00
cross_v3_v3v3(B, no, shi->nmaptang); /* bitangent */
mul_v3_fl(B, shi->nmaptang[3]);
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 */
This commit will switch blender to use tangent space generated within the two files mikktspace.h and mikktspace.c. These are standalone files which can be redistributed into any other application and regenerate the same tangent spaces. The implementation is independent of the ordering of faces and the vertex ordering of faces.
2011-02-14 18:18:46 +00:00
tv[0] = texres.nor[0]*shi->nmaptang[0] + texres.nor[1]*B[0] + texres.nor[2]*no[0];
tv[1] = texres.nor[0]*shi->nmaptang[1] + texres.nor[1]*B[1] + texres.nor[2]*no[1];
tv[2] = texres.nor[0]*shi->nmaptang[2] + texres.nor[1]*B[2] + texres.nor[2]*no[2];
shi->vn[0]= facm*no[0] + fact*tv[0];
shi->vn[1]= facm*no[1] + fact*tv[1];
shi->vn[2]= facm*no[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];
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(nor, texres.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
style cleanup: if();
2012-10-07 09:48:59 +00:00
if (mtex->normapspace == MTEX_NSPACE_CAMERA) {
/* pass */
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->normapspace == MTEX_NSPACE_WORLD) {
Dynamic Paint: * Redesigned alpha blending and paint drying algorithms. Now it gives much better results when using low brush alpha or when surface has initial color set. * Fix: "Slow" dissolve/dry was scaled incorrect when using substeps. Also adjusted time to better match non-"slow" setting. * Fixed possible issues when using image textured brush. * Fix: particle brush panel was no longer visible since last commit. * Adjusted default surface values. * Some more code cleanup.
2011-10-31 13:01:06 +00:00
mul_mat3_m4_v3(re->viewmat, 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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->normapspace == MTEX_NSPACE_OBJECT) {
if (shi->obr && shi->obr->ob)
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
mul_mat3_m4_v3(shi->obr->ob->obmat, nor);
Dynamic Paint: * Redesigned alpha blending and paint drying algorithms. Now it gives much better results when using low brush alpha or when surface has initial color set. * Fix: "Slow" dissolve/dry was scaled incorrect when using substeps. Also adjusted time to better match non-"slow" setting. * Fixed possible issues when using image textured brush. * Fix: particle brush panel was no longer visible since last commit. * Adjusted default surface values. * Some more code cleanup.
2011-10-31 13:01:06 +00:00
mul_mat3_m4_v3(re->viewmat, 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
}
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
normalize_v3(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
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 {
Bugfix #20027 Texture Nodes didn't work for normal output anymore anymore. It was caused by new handling of bump code using derivatives, but that's not how texture nodes work now. In case a texture has nodes, it uses the old (2.4) method.
2010-11-11 16:50:04 +00:00
/* XXX texture node trees don't work for this yet */
new bumpmapping options for the renderer oldbump -> original newbump -> compatible *new* -> default (3tap) *new* -> best quality (5tap) the latter two have an option to apply bumpmapping in viewspace - much like displacement mapping objectspace - default (scales with the object) texturespace - much like normal mapping (scales)
2011-01-29 11:56:11 +00:00
if (use_compat_bump || use_ntap_bump) {
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
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;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->mat->mode & MA_TANGENT_V) {
Fix #21227, #21346 and #21336: image texture wasn't centered correctly when sculpting and using it from material nodes.
2010-03-01 18:11:09 +00:00
shi->tang[0]+= Tnor*norfac*texres.nor[0];
shi->tang[1]+= Tnor*norfac*texres.nor[1];
shi->tang[2]+= Tnor*norfac*texres.nor[2];
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
}
/* prevent bump to become negative normal */
Fix #21227, #21346 and #21336: image texture wasn't centered correctly when sculpting and using it from material nodes.
2010-03-01 18:11:09 +00:00
nor[0]= Tnor*norfac*texres.nor[0];
nor[1]= Tnor*norfac*texres.nor[1];
nor[2]= Tnor*norfac*texres.nor[2];
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
minor edits / cleanup - no functional changes. - use 'const float *' and array size in some function declarations. - replace macros for BLI_math functions INPF, VECCOPY, VECADD etc. - remove unused VertRen.clip struct member. - remove static squared_dist() from 2 files, replace with BLI_math function len_squared_v3v3(). - use vertex arrays for drawing clipping background in the 3D viewport.
2011-09-11 02:50:01 +00:00
dot= 0.5f + 0.5f * dot_v3v3(nor, shi->vn);
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
shi->vn[0]+= dot*nor[0];
shi->vn[1]+= dot*nor[1];
shi->vn[2]+= dot*nor[2];
}
}
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
normalize_v3(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
}
}
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38: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. */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (texres.nor) {
Fix #21227, #21346 and #21336: image texture wasn't centered correctly when sculpting and using it from material nodes.
2010-03-01 18:11:09 +00:00
float norfac= mtex->norfac;
- 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
Fix #21227, #21346 and #21336: image texture wasn't centered correctly when sculpting and using it from material nodes.
2010-03-01 18:11:09 +00:00
shi->displace[0]+= 0.2f*Tnor*norfac*texres.nor[0];
shi->displace[1]+= 0.2f*Tnor*norfac*texres.nor[1];
shi->displace[2]+= 0.2f*Tnor*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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (rgbnor & TEX_RGB) {
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
texres.tin = rgb_to_grayscale(&texres.tr);
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
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
factt= (0.5f-texres.tin)*mtex->dispfac*stencilTin; facmm= 1.0f-factt;
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->blendtype==MTEX_BLEND) {
- 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
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];
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->blendtype==MTEX_MUL) {
- 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
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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->blendtype==MTEX_SUB) factt= -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
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (rgbnor & TEX_RGB) {
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
if (texres.talpha) texres.tin = texres.ta;
else texres.tin = rgb_to_grayscale(&texres.tr);
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & MAP_REF) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float difffac= mtex->difffac*stencilTin;
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
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
shi->refl= texture_value_blend(mtex->def_var, shi->refl, texres.tin, difffac, mtex->blendtype);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->refl<0.0f) shi->refl= 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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & MAP_SPEC) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float specfac= mtex->specfac*stencilTin;
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
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
shi->spec= texture_value_blend(mtex->def_var, shi->spec, texres.tin, specfac, mtex->blendtype);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->spec<0.0f) shi->spec= 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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & MAP_EMIT) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float emitfac= mtex->emitfac*stencilTin;
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
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
shi->emit= texture_value_blend(mtex->def_var, shi->emit, texres.tin, emitfac, mtex->blendtype);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->emit<0.0f) shi->emit= 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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & MAP_ALPHA) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float alphafac= mtex->alphafac*stencilTin;
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
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
shi->alpha= texture_value_blend(mtex->def_var, shi->alpha, texres.tin, alphafac, mtex->blendtype);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->alpha<0.0f) shi->alpha= 0.0f;
else if (shi->alpha>1.0f) shi->alpha= 1.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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & MAP_HAR) {
style cleanup
2012-07-07 22:51:57 +00:00
float har; /* have to map to 0-1 */
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float hardfac= mtex->hardfac*stencilTin;
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
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
har= ((float)shi->har)/128.0f;
har= 128.0f*texture_value_blend(mtex->def_var, har, texres.tin, hardfac, mtex->blendtype);
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (har<1.0f) shi->har= 1;
else if (har>511) shi->har= 511;
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 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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & MAP_RAYMIRR) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float raymirrfac= mtex->raymirrfac*stencilTin;
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
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
shi->ray_mirror= texture_value_blend(mtex->def_var, shi->ray_mirror, texres.tin, raymirrfac, mtex->blendtype);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->ray_mirror<0.0f) shi->ray_mirror= 0.0f;
else if (shi->ray_mirror>1.0f) shi->ray_mirror= 1.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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & MAP_TRANSLU) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float translfac= mtex->translfac*stencilTin;
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
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
shi->translucency= texture_value_blend(mtex->def_var, shi->translucency, texres.tin, translfac, mtex->blendtype);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->translucency<0.0f) shi->translucency= 0.0f;
else if (shi->translucency>1.0f) shi->translucency= 1.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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & MAP_AMB) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float ambfac= mtex->ambfac*stencilTin;
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
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
shi->amb= texture_value_blend(mtex->def_var, shi->amb, texres.tin, ambfac, mtex->blendtype);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->amb<0.0f) shi->amb= 0.0f;
else if (shi->amb>1.0f) shi->amb= 1.0f;
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
Dynamic Paint: * Redesigned alpha blending and paint drying algorithms. Now it gives much better results when using low brush alpha or when surface has initial color set. * Fix: "Slow" dissolve/dry was scaled incorrect when using substeps. Also adjusted time to better match non-"slow" setting. * Fixed possible issues when using image textured brush. * Fix: particle brush panel was no longer visible since last commit. * Adjusted default surface values. * Some more code cleanup.
2011-10-31 13:01:06 +00:00
shi->ambr= shi->amb*re->wrld.ambr;
shi->ambg= shi->amb*re->wrld.ambg;
shi->ambb= shi->amb*re->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
}
}
}
code cleanup: use TRUE/FALSE rather then 1/0 for better readability, also replace do prefix with do_ for bool vars.
2012-05-19 13:28:19 +00:00
if ((use_compat_bump || use_ntap_bump || found_nmapping) && (shi->mat->mode & MA_TANGENT_V) != 0) {
By Morten S. Mikkelsen; this adds support for tangent bump shading left: legacy bump, righ: sparkybump http://pasteall.org/pic/show.php?id=13875 bugs [#26320], [#27506] there's still an issue with texture OSA as you can see
2011-06-19 20:41:41 +00:00
const float fnegdot = -dot_v3v3(shi->vn, shi->tang);
style cleanup
2012-07-07 22:51:57 +00:00
/* apply Gram-Schmidt projection */
By Morten S. Mikkelsen; this adds support for tangent bump shading left: legacy bump, righ: sparkybump http://pasteall.org/pic/show.php?id=13875 bugs [#26320], [#27506] there's still an issue with texture OSA as you can see
2011-06-19 20:41:41 +00:00
madd_v3_v3fl(shi->tang, shi->vn, fnegdot);
normalize_v3(shi->tang);
}
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have to do it themselves. This commit will need quite some testing help, but I'm around!
2003-12-21 21:52:51 +00:00
}
Revert bump mapping patch for now, backwards compatibility is not good enough, we may need to preserve the previous method.
2011-01-07 16:55:56 +00:00
code cleanup: use array size and const for vector args
2012-05-26 16:04:31 +00:00
void do_volume_tex(ShadeInput *shi, const float *xyz, int mapto_flag, float col_r[3], float *val, Render *re)
* 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
{
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
const bool skip_load_image = (re->r.scemode & R_NO_IMAGE_LOAD) != 0;
* 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
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;
Dynamic Paint: * Added "Initial Color" setting for surfaces. You can for example set color from UV mapped texture or from vertex colors. * Added clamping option for "wave" brushes. * Merged smudge and drip adjacency search code. This fixes some issues with drip effect and makes code easier to maintain. * Some adjustments to the bounding box generation code. * OpenMP is now completely disabled if no compile flag is set. * Wetness values are now properly clamped on vertex surfaces. No more black dots on >1.0 wetness. * Textured brushes now use same function calls as internal renderer, instead of modified duplicates. * Moved operator code to editors/physics/. * Re-enabled some particle brush optimizations. * Fixed sometimes incorrect volume brush influence. * Fixed possible crash when using a brush that uses "Voxel Data" texture simultaneously with material preview or render. * Fixed texture mapping issues for "Object Center" brush. * Fixed possible crash/corruption when duplicating brush object that uses color ramps. * Other tweaking and code cleanup.
2011-09-05 16:04:15 +00:00
if (re->r.scemode & R_NO_TEX) return;
* 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
/* here: test flag if there's a tex (todo) */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
for (tex_nr=0; tex_nr<MAX_MTEX; tex_nr++) {
* 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
/* separate tex switching */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->mat->septex & (1<<tex_nr)) continue;
* 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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->mat->mtex[tex_nr]) {
* 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
mtex= shi->mat->mtex[tex_nr];
tex= mtex->tex;
code cleanup: use NULL rather then zero for pointers
2013-08-07 03:30:23 +00:00
if (tex == NULL) continue;
* 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
/* only process if this texture is mapped
* to one that we're interested in */
if (!(mtex->mapto & mapto_flag)) continue;
/* which coords */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texco==TEXCO_OBJECT) {
* 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
Object *ob= mtex->object;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (ob) {
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(co, xyz);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texflag & MTEX_OB_DUPLI_ORIG) {
if (shi->obi && shi->obi->duplitexmat)
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
mul_m4_v3(shi->obi->duplitexmat, co);
}
Bug fix: Render and 3d view conflict over ob->imat * For rendering every object's inverse matrix "ob->imat" needs to be in render view coordinates, but for drawing in 3d view it needs to be in global coordinates. Originally (way back in historical times) ob->imat was only used for rendering, but over the years other uses came up too. Before 2.5 this wasn't a problem as rendering was a totally blocking operation, but with the new "interactive ui while rendering" the problems started. Basically any update that redrew the 3d view while rendering (like rotating the scene with mouse) updated the inverse matrix into global coordinates thus invalidating it for the render, leading to all kinds of strange discontinuities with textures and volumetrics. * Problems were very easy to achieve using orco/object coordinates for pretty much any textures (bump, point density, volume, sky), for examples see bug reports 24906 and 25229. Render baking normals in object coordinates was wrong most of the time too. * Now there is a separate inverse matrix ob->imat_ren that's calculated at the beginning of rendering and is used in all places inside render code where it's needed. This way the original ob->imat can change at will during rendering without causing problems.
2011-02-28 15:42:15 +00:00
mul_m4_v3(ob->imat_ren, co);
Google Summer of Code project: "Smoke Simulator Improvements & Fire". Documentation & Test blend files: ------------------ http://wiki.blender.org/index.php/User:MiikaH/GSoC-2012-Smoke-Simulator-Improvements Credits: ------------------ Miika Hamalainen (MiikaH): Student / Main programmer Daniel Genrich (Genscher): Mentor / Programmer of merged patches from Smoke2 branch Google: For Google Summer of Code 2012
2012-10-10 13:18:07 +00:00
if (mtex->texflag & MTEX_MAPTO_BOUNDS && ob->bb) {
/* use bb vec[0] as min and bb vec[6] as max */
co[0] = (co[0] - ob->bb->vec[0][0]) / (ob->bb->vec[6][0]-ob->bb->vec[0][0]) * 2.0f - 1.0f;
co[1] = (co[1] - ob->bb->vec[0][1]) / (ob->bb->vec[6][1]-ob->bb->vec[0][1]) * 2.0f - 1.0f;
co[2] = (co[2] - ob->bb->vec[0][2]) / (ob->bb->vec[6][2]-ob->bb->vec[0][2]) * 2.0f - 1.0f;
}
* 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' */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->texco==TEXCO_ORCO) {
* 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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texflag & MTEX_DUPLI_MAPTO) {
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(co, shi->duplilo);
* 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 {
Object *ob= shi->obi->ob;
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(co, xyz);
Bug fix: Render and 3d view conflict over ob->imat * For rendering every object's inverse matrix "ob->imat" needs to be in render view coordinates, but for drawing in 3d view it needs to be in global coordinates. Originally (way back in historical times) ob->imat was only used for rendering, but over the years other uses came up too. Before 2.5 this wasn't a problem as rendering was a totally blocking operation, but with the new "interactive ui while rendering" the problems started. Basically any update that redrew the 3d view while rendering (like rotating the scene with mouse) updated the inverse matrix into global coordinates thus invalidating it for the render, leading to all kinds of strange discontinuities with textures and volumetrics. * Problems were very easy to achieve using orco/object coordinates for pretty much any textures (bump, point density, volume, sky), for examples see bug reports 24906 and 25229. Render baking normals in object coordinates was wrong most of the time too. * Now there is a separate inverse matrix ob->imat_ren that's calculated at the beginning of rendering and is used in all places inside render code where it's needed. This way the original ob->imat can change at will during rendering without causing problems.
2011-02-28 15:42:15 +00:00
mul_m4_v3(ob->imat_ren, co);
Google Summer of Code project: "Smoke Simulator Improvements & Fire". Documentation & Test blend files: ------------------ http://wiki.blender.org/index.php/User:MiikaH/GSoC-2012-Smoke-Simulator-Improvements Credits: ------------------ Miika Hamalainen (MiikaH): Student / Main programmer Daniel Genrich (Genscher): Mentor / Programmer of merged patches from Smoke2 branch Google: For Google Summer of Code 2012
2012-10-10 13:18:07 +00:00
if (mtex->texflag & MTEX_MAPTO_BOUNDS && ob->bb) {
/* use bb vec[0] as min and bb vec[6] as max */
co[0] = (co[0] - ob->bb->vec[0][0]) / (ob->bb->vec[6][0]-ob->bb->vec[0][0]) * 2.0f - 1.0f;
co[1] = (co[1] - ob->bb->vec[0][1]) / (ob->bb->vec[6][1]-ob->bb->vec[0][1]) * 2.0f - 1.0f;
co[2] = (co[2] - ob->bb->vec[0][2]) / (ob->bb->vec[6][2]-ob->bb->vec[0][2]) * 2.0f - 1.0f;
}
* 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
}
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->texco==TEXCO_GLOB) {
correct indentation and some whitespace edits (no functional changes)
2011-11-11 13:09:14 +00:00
copy_v3_v3(co, xyz);
mul_m4_v3(re->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
}
style cleanup
2012-07-07 22:51:57 +00:00
else {
continue; /* can happen when texco defines disappear and it renders old files */
}
* 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
texres.nor= NULL;
style cleanup
2012-07-07 22:51:57 +00:00
if (tex->type == TEX_IMAGE) {
continue; /* not supported yet */
* 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
//do_2d_mapping(mtex, texvec, NULL, NULL, dxt, dyt);
}
else {
/* placement */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projx) texvec[0]= mtex->size[0]*(co[mtex->projx-1]+mtex->ofs[0]);
* 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 texvec[0]= mtex->size[0]*(mtex->ofs[0]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projy) texvec[1]= mtex->size[1]*(co[mtex->projy-1]+mtex->ofs[1]);
* 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 texvec[1]= mtex->size[1]*(mtex->ofs[1]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projz) texvec[2]= mtex->size[2]*(co[mtex->projz-1]+mtex->ofs[2]);
* 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 texvec[2]= mtex->size[2]*(mtex->ofs[2]);
}
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
rgbnor = multitex(tex, texvec, NULL, NULL, 0, &texres, shi->thread, mtex->which_output, re->pool, skip_load_image); /* NULL = dxt/dyt, 0 = shi->osatex - not supported */
* 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 output */
Code cleanup: style
2014-03-17 21:48:13 +11:00
if ((rgbnor & TEX_RGB) && (mtex->texflag & MTEX_RGBTOINT)) {
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
texres.tin = rgb_to_grayscale(&texres.tr);
rgbnor -= TEX_RGB;
* 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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texflag & MTEX_NEGATIVE) {
if (rgbnor & TEX_RGB) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
texres.tr= 1.0f-texres.tr;
texres.tg= 1.0f-texres.tg;
texres.tb= 1.0f-texres.tb;
* 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
}
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
texres.tin= 1.0f-texres.tin;
* 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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texflag & MTEX_STENCIL) {
if (rgbnor & TEX_RGB) {
* 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
fact= texres.ta;
texres.ta*= stencilTin;
stencilTin*= fact;
}
else {
fact= texres.tin;
texres.tin*= stencilTin;
stencilTin*= fact;
}
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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))) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float tcol[3];
* 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
/* stencil maps on the texture control slider, not texture intensity value */
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
if ((rgbnor & TEX_RGB) == 0) {
copy_v3_v3(tcol, &mtex->r);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
Google Summer of Code project: "Smoke Simulator Improvements & Fire". Documentation & Test blend files: ------------------ http://wiki.blender.org/index.php/User:MiikaH/GSoC-2012-Smoke-Simulator-Improvements Credits: ------------------ Miika Hamalainen (MiikaH): Student / Main programmer Daniel Genrich (Genscher): Mentor / Programmer of merged patches from Smoke2 branch Google: For Google Summer of Code 2012
2012-10-10 13:18:07 +00:00
else if (mtex->mapto & MAP_DENSITY) {
copy_v3_v3(tcol, &texres.tr);
if (texres.talpha) {
texres.tin = stencilTin;
}
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else {
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +00:00
copy_v3_v3(tcol, &texres.tr);
if (texres.talpha) {
* 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
texres.tin= texres.ta;
code cleanup: color/bw conversion - use BLI color function. change modifier to use the average of the RGB since perceptual conversion isn't really needed for modifiers.
2012-05-09 10:48:24 +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
}
/* used for emit */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ((mapto_flag & MAP_EMISSION_COL) && (mtex->mapto & MAP_EMISSION_COL)) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float colemitfac= mtex->colemitfac*stencilTin;
code cleanup: use array size and const for vector args
2012-05-26 16:04:31 +00:00
texture_rgb_blend(col_r, tcol, col_r, texres.tin, colemitfac, mtex->blendtype);
* 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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ((mapto_flag & MAP_REFLECTION_COL) && (mtex->mapto & MAP_REFLECTION_COL)) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float colreflfac= mtex->colreflfac*stencilTin;
code cleanup: use array size and const for vector args
2012-05-26 16:04:31 +00:00
texture_rgb_blend(col_r, tcol, col_r, texres.tin, colreflfac, 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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ((mapto_flag & MAP_TRANSMISSION_COL) && (mtex->mapto & MAP_TRANSMISSION_COL)) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float coltransfac= mtex->coltransfac*stencilTin;
code cleanup: use array size and const for vector args
2012-05-26 16:04:31 +00:00
texture_rgb_blend(col_r, tcol, col_r, texres.tin, coltransfac, mtex->blendtype);
* 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
}
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ((mapto_flag & MAP_VARS) && (mtex->mapto & MAP_VARS)) {
* 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
/* stencil maps on the texture control slider, not texture intensity value */
/* convert RGB to intensity if intensity info isn't provided */
fix for missing NULL check in init_render_texture() (possibly own fault), also remove some redundant code.
2012-09-19 08:09:22 +00:00
if (rgbnor & TEX_RGB) {
if (texres.talpha) texres.tin = texres.ta;
else texres.tin = rgb_to_grayscale(&texres.tr);
* 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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ((mapto_flag & MAP_EMISSION) && (mtex->mapto & MAP_EMISSION)) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float emitfac= mtex->emitfac*stencilTin;
* 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 stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
*val = texture_value_blend(mtex->def_var, *val, texres.tin, emitfac, mtex->blendtype);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (*val<0.0f) *val= 0.0f;
* 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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ((mapto_flag & MAP_DENSITY) && (mtex->mapto & MAP_DENSITY)) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float densfac= mtex->densfac*stencilTin;
* 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 stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
*val = texture_value_blend(mtex->def_var, *val, texres.tin, densfac, mtex->blendtype);
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
CLAMP(*val, 0.0f, 1.0f);
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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ((mapto_flag & MAP_SCATTERING) && (mtex->mapto & MAP_SCATTERING)) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float scatterfac= mtex->scatterfac*stencilTin;
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
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
*val = texture_value_blend(mtex->def_var, *val, texres.tin, scatterfac, mtex->blendtype);
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
CLAMP(*val, 0.0f, 1.0f);
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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ((mapto_flag & MAP_REFLECTION) && (mtex->mapto & MAP_REFLECTION)) {
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
float reflfac= mtex->reflfac*stencilTin;
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
Texture stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
*val = texture_value_blend(mtex->def_var, *val, texres.tin, reflfac, mtex->blendtype);
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
CLAMP(*val, 0.0f, 1.0f);
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
/* ------------------------------------------------------------------------- */
use vector size and const args where possible (no functional change)
2011-09-12 13:00:24 +00:00
void do_halo_tex(HaloRen *har, float xn, float yn, float col_r[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
{
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
const bool skip_load_image = har->skip_load_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
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];
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (har->mat->septex & (1<<0)) return;
if (mtex->tex==NULL) 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
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projx) texvec[0]= mtex->size[0]*(texvec[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]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projy) texvec[1]= mtex->size[1]*(texvec[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]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projz) texvec[2]= mtex->size[2]*(texvec[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]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (osatex) {
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have to do it themselves. This commit will need quite some testing help, but I'm around!
2003-12-21 21:52:51 +00:00
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
dx= 1.0f/har->rad;
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have to do it themselves. This commit will need quite some testing help, but I'm around!
2003-12-21 21:52:51 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projx) {
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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]= 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;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projy) {
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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[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;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projz) {
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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[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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
rgb = multitex(mtex->tex, texvec, dxt, dyt, osatex, &texres, 0, mtex->which_output, har->pool, skip_load_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
/* texture output */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (rgb && (mtex->texflag & MTEX_RGBTOINT)) {
use an inline function for rgb -> bw conversion.
2012-06-22 07:49:44 +00:00
texres.tin = rgb_to_bw(&texres.tr);
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texflag & MTEX_NEGATIVE) {
if (rgb) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
texres.tr= 1.0f-texres.tr;
texres.tg= 1.0f-texres.tg;
texres.tb= 1.0f-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
}
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
else texres.tin= 1.0f-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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & MAP_COL) {
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have to do it themselves. This commit will need quite some testing help, but I'm around!
2003-12-21 21:52:51 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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 */
Changes to Color Management After testing and feedback, I've decided to slightly modify the way color management works internally. While the previous method worked well for rendering, was a smaller transition and had some advantages over this new method, it was a bit more ambiguous, and was making things difficult for other areas such as compositing. This implementation now considers all color data (with only a couple of exceptions such as brush colors) to be stored in linear RGB color space, rather than sRGB as previously. This brings it in line with Nuke, which also operates this way, quite successfully. Color swatches, pickers, color ramp display are now gamma corrected to display gamma so you can see what you're doing, but the numbers themselves are considered linear. This makes understanding blending modes more clear (a 0.5 value on overlay will not change the result now) as well as making color swatches act more predictably in the compositor, however bringing over color values from applications like photoshop or gimp, that operate in a gamma space, will give identical results. This commit will convert over existing files saved by earlier 2.5 versions to work generally the same, though there may be some slight differences with things like textures. Now that we're set on changing other areas of shading, this won't be too disruptive overall. I've made a diagram explaining the pipeline here: http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png and some docs here: http://www.blender.org/development/release-logs/blender-250/color-management/
2009-12-02 07:56:34 +00:00
if (mtex->tex->type==TEX_IMAGE) {
Image *ima = mtex->tex->ima;
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
ImBuf *ibuf = BKE_image_pool_acquire_ibuf(ima, &mtex->tex->iuser, har->pool);
Changes to Color Management After testing and feedback, I've decided to slightly modify the way color management works internally. While the previous method worked well for rendering, was a smaller transition and had some advantages over this new method, it was a bit more ambiguous, and was making things difficult for other areas such as compositing. This implementation now considers all color data (with only a couple of exceptions such as brush colors) to be stored in linear RGB color space, rather than sRGB as previously. This brings it in line with Nuke, which also operates this way, quite successfully. Color swatches, pickers, color ramp display are now gamma corrected to display gamma so you can see what you're doing, but the numbers themselves are considered linear. This makes understanding blending modes more clear (a 0.5 value on overlay will not change the result now) as well as making color swatches act more predictably in the compositor, however bringing over color values from applications like photoshop or gimp, that operate in a gamma space, will give identical results. This commit will convert over existing files saved by earlier 2.5 versions to work generally the same, though there may be some slight differences with things like textures. Now that we're set on changing other areas of shading, this won't be too disruptive overall. I've made a diagram explaining the pipeline here: http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png and some docs here: http://www.blender.org/development/release-logs/blender-250/color-management/
2009-12-02 07:56:34 +00:00
/* don't linearize float buffers, assumed to be linear */
Color Management: fixed color management-less texture rendering There was a missing check for whether color management enabled or not when converting byte textures to linear space. This commit also fixes wrong texture preview rendering, which was applying sRGB transform twice, making procedural textures bright. This will make float textures being previewed dark (in a linear space) but that's how it used to behave in pre-OCIO color management.
2012-10-10 05:56:49 +00:00
if (ibuf && !(ibuf->rect_float) && R.scene_color_manage)
Color Management, Stage 2: Switch color pipeline to use OpenColorIO Replace old color pipeline which was supporting linear/sRGB color spaces only with OpenColorIO-based pipeline. This introduces two configurable color spaces: - Input color space for images and movie clips. This space is used to convert images/movies from color space in which file is saved to Blender's linear space (for float images, byte images are not internally converted, only input space is stored for such images and used later). This setting could be found in image/clip data block settings. - Display color space which defines space in which particular display is working. This settings could be found in scene's Color Management panel. When render result is being displayed on the screen, apart from converting image to display space, some additional conversions could happen. This conversions are: - View, which defines tone curve applying before display transformation. These are different ways to view the image on the same display device. For example it could be used to emulate film view on sRGB display. - Exposure affects on image exposure before tone map is applied. - Gamma is post-display gamma correction, could be used to match particular display gamma. - RGB curves are user-defined curves which are applying before display transformation, could be used for different purposes. All this settings by default are only applying on render result and does not affect on other images. If some particular image needs to be affected by this transformation, "View as Render" setting of image data block should be set to truth. Movie clips are always affected by all display transformations. This commit also introduces configurable color space in which sequencer is working. This setting could be found in scene's Color Management panel and it should be used if such stuff as grading needs to be done in color space different from sRGB (i.e. when Film view on sRGB display is use, using VD16 space as sequencer's internal space would make grading working in space which is close to the space using for display). Some technical notes: - Image buffer's float buffer is now always in linear space, even if it was created from 16bit byte images. - Space of byte buffer is stored in image buffer's rect_colorspace property. - Profile of image buffer was removed since it's not longer meaningful. - OpenGL and GLSL is supposed to always work in sRGB space. It is possible to support other spaces, but it's quite large project which isn't so much important. - Legacy Color Management option disabled is emulated by using None display. It could have some regressions, but there's no clear way to avoid them. - If OpenColorIO is disabled on build time, it should make blender behaving in the same way as previous release with color management enabled. More details could be found at this page (more details would be added soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management -- Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO integration and to Brecht van Lommel for some further development and code/ usecase review!
2012-09-15 10:05:07 +00:00
IMB_colormanagement_colorspace_to_scene_linear_v3(&texres.tr, ibuf->rect_colorspace);
Image thread safe improvements This commit makes BKE_image_acquire_ibuf referencing result, which means once some area requested for image buffer, it'll be guaranteed this buffer wouldn't be freed by image signal. To de-reference buffer BKE_image_release_ibuf should now always be used. To make referencing working correct we can not rely on result of image_get_ibuf_threadsafe called outside from thread lock. This is so because we need to guarantee getting image buffer from list of loaded buffers and it's referencing happens atomic. Without lock here it is possible that between call of image_get_ibuf_threadsafe and referencing the buffer IMA_SIGNAL_FREE would be called. Image signal handling too is blocking now to prevent such a situation. Threads are locking by spinlock, which are faster than mutexes. There were some slowdown reports in the past about render slowdown when using OSX on Xeon CPU. It shouldn't happen with spin locks, but more tests on different hardware would be really welcome. So far can not see speed regressions on own computers. This commit also removes BKE_image_get_ibuf, because it was not so intuitive when get_ibuf and acquire_ibuf should be used. Thanks to Ton and Brecht for discussion/review :)
2012-11-15 15:59:58 +00:00
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
BKE_image_pool_release_ibuf(ima, ibuf, har->pool);
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
}
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;
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
facm= 1.0f-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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->blendtype==MTEX_MUL) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
facm= 1.0f-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
}
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->blendtype==MTEX_SUB) fact= -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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->blendtype==MTEX_BLEND) {
use vector size and const args where possible (no functional change)
2011-09-12 13:00:24 +00:00
col_r[0]= (fact*texres.tr + facm*har->r);
col_r[1]= (fact*texres.tg + facm*har->g);
col_r[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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->blendtype==MTEX_MUL) {
use vector size and const args where possible (no functional change)
2011-09-12 13:00:24 +00:00
col_r[0]= (facm+fact*texres.tr)*har->r;
col_r[1]= (facm+fact*texres.tg)*har->g;
col_r[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 {
use vector size and const args where possible (no functional change)
2011-09-12 13:00:24 +00:00
col_r[0]= (fact*texres.tr + har->r);
col_r[1]= (fact*texres.tg + har->g);
col_r[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
use vector size and const args where possible (no functional change)
2011-09-12 13:00:24 +00:00
CLAMP(col_r[0], 0.0f, 1.0f);
CLAMP(col_r[1], 0.0f, 1.0f);
CLAMP(col_r[2], 0.0f, 1.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
}
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & MAP_ALPHA) {
if (rgb) {
style cleanup: if();
2012-10-07 09:48:59 +00:00
if (texres.talpha) {
texres.tin = texres.ta;
}
else {
texres.tin = rgb_to_bw(&texres.tr);
}
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have to do it themselves. This commit will need quite some testing help, but I'm around!
2003-12-21 21:52:51 +00:00
}
style cleanup: if();
2012-10-07 09:48:59 +00:00
use vector size and const args where possible (no functional change)
2011-09-12 13:00:24 +00:00
col_r[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 */
use vector size and const args where possible (no functional change)
2011-09-12 13:00:24 +00:00
void do_sky_tex(const float rco[3], float lo[3], const float dxyview[2], float hor[3], float zen[3], 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
{
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
const bool skip_load_image = (R.r.scemode & R_NO_IMAGE_LOAD) != 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
MTex *mtex;
Changes to Color Management After testing and feedback, I've decided to slightly modify the way color management works internally. While the previous method worked well for rendering, was a smaller transition and had some advantages over this new method, it was a bit more ambiguous, and was making things difficult for other areas such as compositing. This implementation now considers all color data (with only a couple of exceptions such as brush colors) to be stored in linear RGB color space, rather than sRGB as previously. This brings it in line with Nuke, which also operates this way, quite successfully. Color swatches, pickers, color ramp display are now gamma corrected to display gamma so you can see what you're doing, but the numbers themselves are considered linear. This makes understanding blending modes more clear (a 0.5 value on overlay will not change the result now) as well as making color swatches act more predictably in the compositor, however bringing over color values from applications like photoshop or gimp, that operate in a gamma space, will give identical results. This commit will convert over existing files saved by earlier 2.5 versions to work generally the same, though there may be some slight differences with things like textures. Now that we're set on changing other areas of shading, this won't be too disruptive overall. I've made a diagram explaining the pipeline here: http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png and some docs here: http://www.blender.org/development/release-logs/blender-250/color-management/
2009-12-02 07:56:34 +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
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];
Fix #29093: world zenith up and down texture influence were not working correct. These were decoupled from horizon influence for 2.5, but not actually used in the render engine.
2011-11-16 15:47:25 +00:00
int 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
/* 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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
for (tex_nr=0; tex_nr<MAX_MTEX; tex_nr++) {
if (R.wrld.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
mtex= R.wrld.mtex[tex_nr];
Changes to Color Management After testing and feedback, I've decided to slightly modify the way color management works internally. While the previous method worked well for rendering, was a smaller transition and had some advantages over this new method, it was a bit more ambiguous, and was making things difficult for other areas such as compositing. This implementation now considers all color data (with only a couple of exceptions such as brush colors) to be stored in linear RGB color space, rather than sRGB as previously. This brings it in line with Nuke, which also operates this way, quite successfully. Color swatches, pickers, color ramp display are now gamma corrected to display gamma so you can see what you're doing, but the numbers themselves are considered linear. This makes understanding blending modes more clear (a 0.5 value on overlay will not change the result now) as well as making color swatches act more predictably in the compositor, however bringing over color values from applications like photoshop or gimp, that operate in a gamma space, will give identical results. This commit will convert over existing files saved by earlier 2.5 versions to work generally the same, though there may be some slight differences with things like textures. Now that we're set on changing other areas of shading, this won't be too disruptive overall. I've made a diagram explaining the pipeline here: http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png and some docs here: http://www.blender.org/development/release-logs/blender-250/color-management/
2009-12-02 07:56:34 +00:00
tex= mtex->tex;
code cleanup: use NULL rather then zero for pointers
2013-08-07 03:30:23 +00:00
if (tex == NULL) continue;
style cleanup: follow style guide for/with/if spacing
2012-03-24 07:52:14 +00:00
/* if (mtex->mapto==0) continue; */
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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 */
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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (dxyview) {
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
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 */
style cleanup: changes to brace placement / newlines - for/while/if/switch
2012-04-28 06:31:57 +00:00
switch (mtex->texco) {
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_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" */
Cleanup: typo
2014-11-21 14:14:50 +01:00
/* use saacos(), fixes bug [#22398], float precision caused lo[2] to be slightly less than -1.0 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (lo[0] || lo[1]) { /* check for zero case [#24807] */
quiet -Wdouble-promotion warnings
2011-11-11 12:00:08 +00:00
fact= (1.0f/(float)M_PI)*saacos(lo[2])/(sqrtf(lo[0]*lo[0] + lo[1]*lo[1]));
bugfix [#24807] nan pixel on Word BG with Angular Map coord texture also avoid divide by zero with an empty raytree
2010-11-19 10:24:14 +00:00
tempvec[0]= lo[0]*fact;
tempvec[1]= lo[1]*fact;
tempvec[2]= 0.0;
}
else {
/* this value has no angle, the vector is directly along the view.
code cleanup: spelling
2012-07-16 23:23:33 +00:00
* avoid divide by zero and use a dummy value. */
bugfix [#24807] nan pixel on Word BG with Angular Map coord texture also avoid divide by zero with an empty raytree
2010-11-19 10:24:14 +00:00
tempvec[0]= 1.0f;
tempvec[1]= 0.0;
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:
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (skyflag & WO_ZENUP) {
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
if (mtex->texco==TEXCO_H_TUBEMAP) map_to_tube( tempvec, tempvec+1, lo[0], lo[2], lo[1]);
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
else map_to_sphere(tempvec, tempvec+1, lo[0], lo[2], lo[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 */
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
tempvec[0]= 1.0f-tempvec[0];
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
/* only top half */
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
tempvec[1]= 2.0f*tempvec[1]-1.0f;
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
tempvec[2]= 0.0;
/* and correction for do_2d_mapping */
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
tempvec[0]= 2.0f*tempvec[0]-1.0f;
tempvec[1]= 2.0f*tempvec[1]-1.0f;
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
co= tempvec;
}
else {
/* potentially dangerous... check with multitex! */
continue;
}
break;
patch [#28094] New equirectangular world texture mapping option
2011-12-19 23:52:17 +00:00
case TEXCO_EQUIRECTMAP:
tempvec[0]= atan2f(lo[0], lo[2]) / (float)M_PI;
tempvec[1]= 1.0f - 2.0f*saacos(lo[1]) / (float)M_PI;
tempvec[2]= 0.0f;
co= tempvec;
break;
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_OBJECT:
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->object) {
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(tempvec, lo);
Bug fix: Render and 3d view conflict over ob->imat * For rendering every object's inverse matrix "ob->imat" needs to be in render view coordinates, but for drawing in 3d view it needs to be in global coordinates. Originally (way back in historical times) ob->imat was only used for rendering, but over the years other uses came up too. Before 2.5 this wasn't a problem as rendering was a totally blocking operation, but with the new "interactive ui while rendering" the problems started. Basically any update that redrew the 3d view while rendering (like rotating the scene with mouse) updated the inverse matrix into global coordinates thus invalidating it for the render, leading to all kinds of strange discontinuities with textures and volumetrics. * Problems were very easy to achieve using orco/object coordinates for pretty much any textures (bump, point density, volume, sky), for examples see bug reports 24906 and 25229. Render baking normals in object coordinates was wrong most of the time too. * Now there is a separate inverse matrix ob->imat_ren that's calculated at the beginning of rendering and is used in all places inside render code where it's needed. This way the original ob->imat can change at will during rendering without causing problems.
2011-02-28 15:42:15 +00:00
mul_m4_v3(mtex->object->imat_ren, 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:
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (rco) {
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(tempvec, rco);
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
mul_m4_v3(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;
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
// copy_v3_v3(shi->dxgl, shi->dxco);
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
// mul_m3_v3(R.imat, shi->dxco);
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
// copy_v3_v3(shi->dygl, shi->dyco);
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
// mul_m3_v3(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
}
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
/* placement */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projx) 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]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projy) 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]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projz) 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]);
/* texture */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (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
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
rgb = multitex(mtex->tex, texvec, dxt, dyt, R.osa, &texres, thread, mtex->which_output, R.pool, skip_load_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
/* texture output */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (rgb && (mtex->texflag & MTEX_RGBTOINT)) {
use an inline function for rgb -> bw conversion.
2012-06-22 07:49:44 +00:00
texres.tin = rgb_to_bw(&texres.tr);
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texflag & MTEX_NEGATIVE) {
if (rgb) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
texres.tr= 1.0f-texres.tr;
texres.tg= 1.0f-texres.tg;
texres.tb= 1.0f-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
}
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
else texres.tin= 1.0f-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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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 {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (rgb) texres.ta *= stencilTin;
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*= 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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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 */
Changes to Color Management After testing and feedback, I've decided to slightly modify the way color management works internally. While the previous method worked well for rendering, was a smaller transition and had some advantages over this new method, it was a bit more ambiguous, and was making things difficult for other areas such as compositing. This implementation now considers all color data (with only a couple of exceptions such as brush colors) to be stored in linear RGB color space, rather than sRGB as previously. This brings it in line with Nuke, which also operates this way, quite successfully. Color swatches, pickers, color ramp display are now gamma corrected to display gamma so you can see what you're doing, but the numbers themselves are considered linear. This makes understanding blending modes more clear (a 0.5 value on overlay will not change the result now) as well as making color swatches act more predictably in the compositor, however bringing over color values from applications like photoshop or gimp, that operate in a gamma space, will give identical results. This commit will convert over existing files saved by earlier 2.5 versions to work generally the same, though there may be some slight differences with things like textures. Now that we're set on changing other areas of shading, this won't be too disruptive overall. I've made a diagram explaining the pipeline here: http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png and some docs here: http://www.blender.org/development/release-logs/blender-250/color-management/
2009-12-02 07:56:34 +00:00
if (tex->type==TEX_IMAGE) {
Image *ima = tex->ima;
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
ImBuf *ibuf = BKE_image_pool_acquire_ibuf(ima, &tex->iuser, R.pool);
Changes to Color Management After testing and feedback, I've decided to slightly modify the way color management works internally. While the previous method worked well for rendering, was a smaller transition and had some advantages over this new method, it was a bit more ambiguous, and was making things difficult for other areas such as compositing. This implementation now considers all color data (with only a couple of exceptions such as brush colors) to be stored in linear RGB color space, rather than sRGB as previously. This brings it in line with Nuke, which also operates this way, quite successfully. Color swatches, pickers, color ramp display are now gamma corrected to display gamma so you can see what you're doing, but the numbers themselves are considered linear. This makes understanding blending modes more clear (a 0.5 value on overlay will not change the result now) as well as making color swatches act more predictably in the compositor, however bringing over color values from applications like photoshop or gimp, that operate in a gamma space, will give identical results. This commit will convert over existing files saved by earlier 2.5 versions to work generally the same, though there may be some slight differences with things like textures. Now that we're set on changing other areas of shading, this won't be too disruptive overall. I've made a diagram explaining the pipeline here: http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png and some docs here: http://www.blender.org/development/release-logs/blender-250/color-management/
2009-12-02 07:56:34 +00:00
/* don't linearize float buffers, assumed to be linear */
Color Management: fixed color management-less texture rendering There was a missing check for whether color management enabled or not when converting byte textures to linear space. This commit also fixes wrong texture preview rendering, which was applying sRGB transform twice, making procedural textures bright. This will make float textures being previewed dark (in a linear space) but that's how it used to behave in pre-OCIO color management.
2012-10-10 05:56:49 +00:00
if (ibuf && !(ibuf->rect_float) && R.scene_color_manage)
Color Management, Stage 2: Switch color pipeline to use OpenColorIO Replace old color pipeline which was supporting linear/sRGB color spaces only with OpenColorIO-based pipeline. This introduces two configurable color spaces: - Input color space for images and movie clips. This space is used to convert images/movies from color space in which file is saved to Blender's linear space (for float images, byte images are not internally converted, only input space is stored for such images and used later). This setting could be found in image/clip data block settings. - Display color space which defines space in which particular display is working. This settings could be found in scene's Color Management panel. When render result is being displayed on the screen, apart from converting image to display space, some additional conversions could happen. This conversions are: - View, which defines tone curve applying before display transformation. These are different ways to view the image on the same display device. For example it could be used to emulate film view on sRGB display. - Exposure affects on image exposure before tone map is applied. - Gamma is post-display gamma correction, could be used to match particular display gamma. - RGB curves are user-defined curves which are applying before display transformation, could be used for different purposes. All this settings by default are only applying on render result and does not affect on other images. If some particular image needs to be affected by this transformation, "View as Render" setting of image data block should be set to truth. Movie clips are always affected by all display transformations. This commit also introduces configurable color space in which sequencer is working. This setting could be found in scene's Color Management panel and it should be used if such stuff as grading needs to be done in color space different from sRGB (i.e. when Film view on sRGB display is use, using VD16 space as sequencer's internal space would make grading working in space which is close to the space using for display). Some technical notes: - Image buffer's float buffer is now always in linear space, even if it was created from 16bit byte images. - Space of byte buffer is stored in image buffer's rect_colorspace property. - Profile of image buffer was removed since it's not longer meaningful. - OpenGL and GLSL is supposed to always work in sRGB space. It is possible to support other spaces, but it's quite large project which isn't so much important. - Legacy Color Management option disabled is emulated by using None display. It could have some regressions, but there's no clear way to avoid them. - If OpenColorIO is disabled on build time, it should make blender behaving in the same way as previous release with color management enabled. More details could be found at this page (more details would be added soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management -- Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO integration and to Brecht van Lommel for some further development and code/ usecase review!
2012-09-15 10:05:07 +00:00
IMB_colormanagement_colorspace_to_scene_linear_v3(tcol, ibuf->rect_colorspace);
Image thread safe improvements This commit makes BKE_image_acquire_ibuf referencing result, which means once some area requested for image buffer, it'll be guaranteed this buffer wouldn't be freed by image signal. To de-reference buffer BKE_image_release_ibuf should now always be used. To make referencing working correct we can not rely on result of image_get_ibuf_threadsafe called outside from thread lock. This is so because we need to guarantee getting image buffer from list of loaded buffers and it's referencing happens atomic. Without lock here it is possible that between call of image_get_ibuf_threadsafe and referencing the buffer IMA_SIGNAL_FREE would be called. Image signal handling too is blocking now to prevent such a situation. Threads are locking by spinlock, which are faster than mutexes. There were some slowdown reports in the past about render slowdown when using OSX on Xeon CPU. It shouldn't happen with spin locks, but more tests on different hardware would be really welcome. So far can not see speed regressions on own computers. This commit also removes BKE_image_get_ibuf, because it was not so intuitive when get_ibuf and acquire_ibuf should be used. Thanks to Ton and Brecht for discussion/review :)
2012-11-15 15:59:58 +00:00
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
BKE_image_pool_release_ibuf(ima, ibuf, R.pool);
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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & (WOMAP_ZENUP+WOMAP_ZENDOWN)) {
Fix #29093: world zenith up and down texture influence were not working correct. These were decoupled from horizon influence for 2.5, but not actually used in the render engine.
2011-11-16 15:47:25 +00:00
float zenfac = 0.0f;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (R.wrld.skytype & WO_SKYREAL) {
if ((skyflag & WO_ZENUP)) {
if (mtex->mapto & WOMAP_ZENUP) zenfac= mtex->zenupfac;
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have to do it themselves. This commit will need quite some testing help, but I'm around!
2003-12-21 21:52:51 +00:00
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->mapto & WOMAP_ZENDOWN) zenfac= mtex->zendownfac;
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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 #29093: world zenith up and down texture influence were not working correct. These were decoupled from horizon influence for 2.5, but not actually used in the render engine.
2011-11-16 15:47:25 +00:00
else {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & WOMAP_ZENUP) zenfac= mtex->zenupfac;
else if (mtex->mapto & WOMAP_ZENDOWN) zenfac= mtex->zendownfac;
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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 #29093: world zenith up and down texture influence were not working correct. These were decoupled from horizon influence for 2.5, but not actually used in the render engine.
2011-11-16 15:47:25 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (zenfac != 0.0f)
Fix #29093: world zenith up and down texture influence were not working correct. These were decoupled from horizon influence for 2.5, but not actually used in the render engine.
2011-11-16 15:47:25 +00:00
texture_rgb_blend(zen, tcol, zen, texres.tin, zenfac, 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
}
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->mapto & WOMAP_BLEND) {
use an inline function for rgb -> bw conversion.
2012-06-22 07:49:44 +00:00
if (rgb) texres.tin = rgb_to_bw(&texres.tr);
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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 stack influences are now all separate values, and negative mapped values now have their influence negated instead. Also a few RNA changes for TextureSlot. Bumped subversion for the version patch.
2009-10-01 17:15:23 +00:00
*blend= texture_value_blend(mtex->def_var, *blend, texres.tin, mtex->blendfac, 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
}
}
}
}
/* ------------------------------------------------------------------------- */
use vector size and const args where possible (no functional change)
2011-09-12 13:00:24 +00:00
/* col_r supposed to be initialized with la->r,g,b */
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
use vector size and const args where possible (no functional change)
2011-09-12 13:00:24 +00:00
void do_lamp_tex(LampRen *la, const float lavec[3], ShadeInput *shi, float col_r[3], 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
{
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
const bool skip_load_image = (R.r.scemode & R_NO_IMAGE_LOAD) != 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
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;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (la->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
mtex= la->mtex[tex_nr];
tex= mtex->tex;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex==NULL) continue;
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
/* which coords */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texco==TEXCO_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
ob= mtex->object;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (ob) {
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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;
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(tempvec, shi->co);
Bug fix: Render and 3d view conflict over ob->imat * For rendering every object's inverse matrix "ob->imat" needs to be in render view coordinates, but for drawing in 3d view it needs to be in global coordinates. Originally (way back in historical times) ob->imat was only used for rendering, but over the years other uses came up too. Before 2.5 this wasn't a problem as rendering was a totally blocking operation, but with the new "interactive ui while rendering" the problems started. Basically any update that redrew the 3d view while rendering (like rotating the scene with mouse) updated the inverse matrix into global coordinates thus invalidating it for the render, leading to all kinds of strange discontinuities with textures and volumetrics. * Problems were very easy to achieve using orco/object coordinates for pretty much any textures (bump, point density, volume, sky), for examples see bug reports 24906 and 25229. Render baking normals in object coordinates was wrong most of the time too. * Now there is a separate inverse matrix ob->imat_ren that's calculated at the beginning of rendering and is used in all places inside render code where it's needed. This way the original ob->imat can change at will during rendering without causing problems.
2011-02-28 15:42:15 +00:00
mul_m4_v3(ob->imat_ren, tempvec);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->osatex) {
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(dxt, shi->dxco);
copy_v3_v3(dyt, shi->dyco);
Bug fix: Render and 3d view conflict over ob->imat * For rendering every object's inverse matrix "ob->imat" needs to be in render view coordinates, but for drawing in 3d view it needs to be in global coordinates. Originally (way back in historical times) ob->imat was only used for rendering, but over the years other uses came up too. Before 2.5 this wasn't a problem as rendering was a totally blocking operation, but with the new "interactive ui while rendering" the problems started. Basically any update that redrew the 3d view while rendering (like rotating the scene with mouse) updated the inverse matrix into global coordinates thus invalidating it for the render, leading to all kinds of strange discontinuities with textures and volumetrics. * Problems were very easy to achieve using orco/object coordinates for pretty much any textures (bump, point density, volume, sky), for examples see bug reports 24906 and 25229. Render baking normals in object coordinates was wrong most of the time too. * Now there is a separate inverse matrix ob->imat_ren that's calculated at the beginning of rendering and is used in all places inside render code where it's needed. This way the original ob->imat can change at will during rendering without causing problems.
2011-02-28 15:42:15 +00:00
mul_mat3_m4_v3(ob->imat_ren, dxt);
mul_mat3_m4_v3(ob->imat_ren, 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
}
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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;
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(shi->gl, shi->co);
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
mul_m4_v3(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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (mtex->texco==TEXCO_VIEW) {
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have to do it themselves. This commit will need quite some testing help, but I'm around!
2003-12-21 21:52:51 +00:00
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(tempvec, lavec);
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
mul_m3_v3(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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (la->type==LA_SPOT) {
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
tempvec[0]*= la->spottexfac;
tempvec[1]*= la->spottexfac;
whitespace only, no functional change mixed tabs/spaces --> tabs.
2011-04-21 13:11:51 +00:00
/* project from 3d to 2d */
Fix #22749: texture view mapping for spot lamps wasn't doing perspective division, giving incorrect projection.
2010-07-26 14:46:16 +00:00
tempvec[0] /= -tempvec[2];
tempvec[1] /= -tempvec[2];
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
}
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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;
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
dx= dxt; dy= dyt;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->osatex) {
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3(dxt, shi->dxlv);
copy_v3_v3(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!!! **/
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
mul_m3_v3(la->imat, dxt);
mul_m3_v3(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
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
mul_v3_fl(dxt, la->spottexfac);
mul_v3_fl(dyt, 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
}
}
/* placement */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
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) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
for (i=0;i<2;i++) {
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
dxt[i] = dyt[i] = 0.0;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
else {
if (mtex->projx) {
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
dxt[0]= mtex->size[0]*dx[mtex->projx-1];
dyt[0]= mtex->size[0]*dy[mtex->projx-1];
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
else {
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
dxt[0]= 0.0;
dyt[0]= 0.0;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projy) {
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
dxt[1]= mtex->size[1]*dx[mtex->projy-1];
dyt[1]= mtex->size[1]*dy[mtex->projy-1];
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
else {
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
dxt[1]= 0.0;
dyt[1]= 0.0;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projz) {
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
dxt[2]= mtex->size[2]*dx[mtex->projz-1];
dyt[2]= mtex->size[2]*dy[mtex->projz-1];
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
else {
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
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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
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
}
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
rgb = multitex(tex, texvec, dxt, dyt, shi->osatex, &texres, shi->thread, mtex->which_output, R.pool, skip_load_image);
- 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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (rgb && (mtex->texflag & MTEX_RGBTOINT)) {
use an inline function for rgb -> bw conversion.
2012-06-22 07:49:44 +00:00
texres.tin = rgb_to_bw(&texres.tr);
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texflag & MTEX_NEGATIVE) {
if (rgb) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
texres.tr= 1.0f-texres.tr;
texres.tg= 1.0f-texres.tg;
texres.tb= 1.0f-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
}
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
else texres.tin= 1.0f-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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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 {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (rgb) texres.ta*= stencilTin;
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*= 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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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 */
Changes to Color Management After testing and feedback, I've decided to slightly modify the way color management works internally. While the previous method worked well for rendering, was a smaller transition and had some advantages over this new method, it was a bit more ambiguous, and was making things difficult for other areas such as compositing. This implementation now considers all color data (with only a couple of exceptions such as brush colors) to be stored in linear RGB color space, rather than sRGB as previously. This brings it in line with Nuke, which also operates this way, quite successfully. Color swatches, pickers, color ramp display are now gamma corrected to display gamma so you can see what you're doing, but the numbers themselves are considered linear. This makes understanding blending modes more clear (a 0.5 value on overlay will not change the result now) as well as making color swatches act more predictably in the compositor, however bringing over color values from applications like photoshop or gimp, that operate in a gamma space, will give identical results. This commit will convert over existing files saved by earlier 2.5 versions to work generally the same, though there may be some slight differences with things like textures. Now that we're set on changing other areas of shading, this won't be too disruptive overall. I've made a diagram explaining the pipeline here: http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png and some docs here: http://www.blender.org/development/release-logs/blender-250/color-management/
2009-12-02 07:56:34 +00:00
if (tex->type==TEX_IMAGE) {
Image *ima = tex->ima;
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
ImBuf *ibuf = BKE_image_pool_acquire_ibuf(ima, &tex->iuser, R.pool);
Changes to Color Management After testing and feedback, I've decided to slightly modify the way color management works internally. While the previous method worked well for rendering, was a smaller transition and had some advantages over this new method, it was a bit more ambiguous, and was making things difficult for other areas such as compositing. This implementation now considers all color data (with only a couple of exceptions such as brush colors) to be stored in linear RGB color space, rather than sRGB as previously. This brings it in line with Nuke, which also operates this way, quite successfully. Color swatches, pickers, color ramp display are now gamma corrected to display gamma so you can see what you're doing, but the numbers themselves are considered linear. This makes understanding blending modes more clear (a 0.5 value on overlay will not change the result now) as well as making color swatches act more predictably in the compositor, however bringing over color values from applications like photoshop or gimp, that operate in a gamma space, will give identical results. This commit will convert over existing files saved by earlier 2.5 versions to work generally the same, though there may be some slight differences with things like textures. Now that we're set on changing other areas of shading, this won't be too disruptive overall. I've made a diagram explaining the pipeline here: http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png and some docs here: http://www.blender.org/development/release-logs/blender-250/color-management/
2009-12-02 07:56:34 +00:00
/* don't linearize float buffers, assumed to be linear */
Color Management: fixed color management-less texture rendering There was a missing check for whether color management enabled or not when converting byte textures to linear space. This commit also fixes wrong texture preview rendering, which was applying sRGB transform twice, making procedural textures bright. This will make float textures being previewed dark (in a linear space) but that's how it used to behave in pre-OCIO color management.
2012-10-10 05:56:49 +00:00
if (ibuf && !(ibuf->rect_float) && R.scene_color_manage)
Color Management, Stage 2: Switch color pipeline to use OpenColorIO Replace old color pipeline which was supporting linear/sRGB color spaces only with OpenColorIO-based pipeline. This introduces two configurable color spaces: - Input color space for images and movie clips. This space is used to convert images/movies from color space in which file is saved to Blender's linear space (for float images, byte images are not internally converted, only input space is stored for such images and used later). This setting could be found in image/clip data block settings. - Display color space which defines space in which particular display is working. This settings could be found in scene's Color Management panel. When render result is being displayed on the screen, apart from converting image to display space, some additional conversions could happen. This conversions are: - View, which defines tone curve applying before display transformation. These are different ways to view the image on the same display device. For example it could be used to emulate film view on sRGB display. - Exposure affects on image exposure before tone map is applied. - Gamma is post-display gamma correction, could be used to match particular display gamma. - RGB curves are user-defined curves which are applying before display transformation, could be used for different purposes. All this settings by default are only applying on render result and does not affect on other images. If some particular image needs to be affected by this transformation, "View as Render" setting of image data block should be set to truth. Movie clips are always affected by all display transformations. This commit also introduces configurable color space in which sequencer is working. This setting could be found in scene's Color Management panel and it should be used if such stuff as grading needs to be done in color space different from sRGB (i.e. when Film view on sRGB display is use, using VD16 space as sequencer's internal space would make grading working in space which is close to the space using for display). Some technical notes: - Image buffer's float buffer is now always in linear space, even if it was created from 16bit byte images. - Space of byte buffer is stored in image buffer's rect_colorspace property. - Profile of image buffer was removed since it's not longer meaningful. - OpenGL and GLSL is supposed to always work in sRGB space. It is possible to support other spaces, but it's quite large project which isn't so much important. - Legacy Color Management option disabled is emulated by using None display. It could have some regressions, but there's no clear way to avoid them. - If OpenColorIO is disabled on build time, it should make blender behaving in the same way as previous release with color management enabled. More details could be found at this page (more details would be added soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management -- Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO integration and to Brecht van Lommel for some further development and code/ usecase review!
2012-09-15 10:05:07 +00:00
IMB_colormanagement_colorspace_to_scene_linear_v3(&texres.tr, ibuf->rect_colorspace);
Image thread safe improvements This commit makes BKE_image_acquire_ibuf referencing result, which means once some area requested for image buffer, it'll be guaranteed this buffer wouldn't be freed by image signal. To de-reference buffer BKE_image_release_ibuf should now always be used. To make referencing working correct we can not rely on result of image_get_ibuf_threadsafe called outside from thread lock. This is so because we need to guarantee getting image buffer from list of loaded buffers and it's referencing happens atomic. Without lock here it is possible that between call of image_get_ibuf_threadsafe and referencing the buffer IMA_SIGNAL_FREE would be called. Image signal handling too is blocking now to prevent such a situation. Threads are locking by spinlock, which are faster than mutexes. There were some slowdown reports in the past about render slowdown when using OSX on Xeon CPU. It shouldn't happen with spin locks, but more tests on different hardware would be really welcome. So far can not see speed regressions on own computers. This commit also removes BKE_image_get_ibuf, because it was not so intuitive when get_ibuf and acquire_ibuf should be used. Thanks to Ton and Brecht for discussion/review :)
2012-11-15 15:59:58 +00:00
Fixed render time regression in Blender Internal It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation.
2013-01-21 08:49:42 +00:00
BKE_image_pool_release_ibuf(ima, ibuf, R.pool);
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
}
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;
Fix T41957: Shadow color texture mapping was using wrong factor
2014-10-07 12:30:23 +02:00
if (effect & LA_SHAD_TEX)
texture_rgb_blend(col_r, col, col_r, texres.tin, mtex->shadowfac, mtex->blendtype);
else
texture_rgb_blend(col_r, col, col_r, 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
}
}
}
}
/* ------------------------------------------------------------------------- */
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
int externtex(MTex *mtex, const float vec[3], float *tin, float *tr, float *tg, float *tb, float *ta, const int thread, struct ImagePool *pool, const bool skip_load_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
{
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;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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 */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projx) texvec[0]= mtex->size[0]*(vec[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]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projy) texvec[1]= mtex->size[1]*(vec[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]);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->projz) texvec[2]= mtex->size[2]*(vec[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]);
/* texture */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
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
}
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
rgb = multitex(tex, texvec, dxt, dyt, 0, &texr, thread, mtex->which_output, pool, skip_load_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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (rgb) {
use an inline function for rgb -> bw conversion.
2012-06-22 07:49:44 +00:00
texr.tin = rgb_to_bw(&texr.tr);
Phew, a lot of work, and no new features... Main target was to make the inner rendering loop using no globals anymore. This is essential for proper usage while raytracing, it caused a lot of hacks in the raycode as well, which even didn't work correctly for all situations (textures especially). Done this by creating a new local struct RenderInput, which replaces usage of the global struct Render R. The latter now only is used to denote image size, viewmatrix, and the like. Making the inner render loops using no globals caused 1000s of vars to be changed... but the result definitely is much nicer code, which enables making 'real' shaders in a next stage. It also enabled me to remove the hacks from ray.c Then i went to the task of removing redundant code. Especially the calculus of texture coords took place (identical) in three locations. Most obvious is the change in the unified render part, which is much less code now; it uses the same rendering routines as normal render now. (Note; not for halos yet!) I also removed 6 files called 'shadowbuffer' something. This was experimen- tal stuff from NaN days. And again saved a lot of double used code. Finally I went over the blenkernel and blender/src calls to render stuff. Here the same local data is used now, resulting in less dependency. I also moved render-texture to the render module, this was still in Kernel. (new file: texture.c) So! After this commit I will check on the autofiles, to try to fix that. MSVC people have 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
{
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
const bool skip_load_image = (R.r.scemode & R_NO_IMAGE_LOAD) != 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
TexResult texr;
style cleanup
2012-07-07 22:51:57 +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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (R.r.scemode & R_NO_TEX) return;
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +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);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (firsttime) {
for (a=0; a<BLENDER_MAX_THREADS; a++) {
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
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;
Fix crash rendering material with "Face Textures" option. Example file: lib/tests/materials/crystal_cube.blend
2013-05-06 14:00:28 +00:00
tex->ima = ima;
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
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
texvec[0]= 0.5f+0.5f*suv->uv[0];
texvec[1]= 0.5f+0.5f*suv->uv[1];
style cleanup
2012-07-07 22:51:57 +00:00
texvec[2] = 0.0f; /* initalize it because imagewrap looks at it. */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (shi->osatex) {
floats were being promoted to doubles in quite a few cases (using gcc's -Wdouble-promotion), went over render module and use float constants, gives small but consistent speedup - approx 3%.
2011-08-20 17:39:13 +00:00
dx[0]= 0.5f*suv->dxuv[0];
dx[1]= 0.5f*suv->dxuv[1];
dy[0]= 0.5f*suv->dyuv[0];
dy[1]= 0.5f*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;
Fix T43427: Particle system children sometimes not generated on reload The issue was caused by the conflict between preview render which would set R_NO_IMAGE_LOAD flag on the renderer and texture samplers called outside of the render pipeline trying to use this flag. Now the sampler functions accepts extra argument so render pipeline can still skip image load, but calls outside of the pipeline will nicely load all the images. Not cleanest change in the world but good enough to unlock gooseberry team, and assuming we already had pool passed all over the place it should be all fine. Will need to reshuffle arguments into SamplerOptions structure later.
2015-01-27 16:14:53 +05:00
if (shi->osatex) imagewraposa(tex, ima, NULL, texvec, dx, dy, &texr, R.pool, skip_load_image);
else imagewrap(tex, ima, NULL, texvec, &texr, R.pool, skip_load_image);
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
}
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
/* A modified part of shadeinput.c -> shade_input_set_uv()
style cleanup: comment blocks
2012-03-09 18:28:30 +00:00
* Used for sampling UV mapped texture color */
code cleanup: use array size and const for vector args
2012-05-26 16:04:31 +00:00
static void textured_face_generate_uv(float *uv, const float normal[3], float *hit, float *v1, float *v2, float *v3)
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
{
de-duplicate dominant axis calculation, exact same checks were in 6 different places. added function: axis_dominant_v3(...)
2011-12-02 22:14:20 +00:00
float detsh, t00, t10, t01, t11;
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
int axis1, axis2;
/* find most stable axis to project */
de-duplicate dominant axis calculation, exact same checks were in 6 different places. added function: axis_dominant_v3(...)
2011-12-02 22:14:20 +00:00
axis_dominant_v3(&axis1, &axis2, normal);
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
/* compute u,v and derivatives */
t00= v3[axis1]-v1[axis1]; t01= v3[axis2]-v1[axis2];
t10= v3[axis1]-v2[axis1]; t11= v3[axis2]-v2[axis2];
detsh= 1.0f/(t00*t11-t10*t01);
t00*= detsh; t01*=detsh;
t10*=detsh; t11*=detsh;
uv[0] = (hit[axis1]-v3[axis1])*t11-(hit[axis2]-v3[axis2])*t10;
uv[1] = (hit[axis2]-v3[axis2])*t00-(hit[axis1]-v3[axis1])*t01;
/* u and v are in range -1 to 0, we allow a little bit extra but not too much, screws up speedvectors */
CLAMP(uv[0], -2.0f, 1.0f);
CLAMP(uv[1], -2.0f, 1.0f);
}
/* Generate an updated copy of material to use for color sampling. */
Material *RE_init_sample_material(Material *orig_mat, Scene *scene)
{
Tex *tex = NULL;
Material *mat;
int tex_nr;
if (!orig_mat) return NULL;
/* copy material */
mat = localize_material(orig_mat);
/* update material anims */
code cleanup: BKE_scene api naming. also stop numpy from being found in /usr/include with cmake.
2012-05-05 14:33:36 +00:00
BKE_animsys_evaluate_animdata(scene, &mat->id, mat->adt, BKE_scene_frame_get(scene), ADT_RECALC_ANIM);
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
/* strip material copy from unsupported flags */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
for (tex_nr=0; tex_nr<MAX_MTEX; tex_nr++) {
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mat->mtex[tex_nr]) {
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
MTex *mtex = mat->mtex[tex_nr];
Fix T37359: Dynamic Paint deletes inactive texture from smoke domain when using a material as brush color
2013-11-22 15:25:19 +02:00
/* just in case make all non-used mtexes empty*/
Tex *cur_tex = mtex->tex;
mtex->tex = NULL;
if (mat->septex & (1<<tex_nr) || !cur_tex) continue;
Fix #30413: dynamic paint crash with texture slots with no texture assigned.
2012-03-01 20:41:13 +00:00
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
/* only keep compatible texflags */
mtex->texflag = mtex->texflag & (MTEX_RGBTOINT | MTEX_STENCIL | MTEX_NEGATIVE | MTEX_ALPHAMIX);
/* depending of material type, strip non-compatible mapping modes */
if (mat->material_type == MA_TYPE_SURFACE) {
Defines: replace ELEM3-16 with ELEM(...), that can take varargs
2014-07-20 01:30:29 +10:00
if (!ELEM(mtex->texco, TEXCO_ORCO, TEXCO_OBJECT, TEXCO_GLOB, TEXCO_UV)) {
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
/* ignore this texture */
mtex->texco = 0;
continue;
}
/* strip all mapto flags except color and alpha */
mtex->mapto = (mtex->mapto & MAP_COL) | (mtex->mapto & MAP_ALPHA);
}
else if (mat->material_type == MA_TYPE_VOLUME) {
Defines: replace ELEM3-16 with ELEM(...), that can take varargs
2014-07-20 01:30:29 +10:00
if (!ELEM(mtex->texco, TEXCO_OBJECT, TEXCO_ORCO, TEXCO_GLOB)) {
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
/* ignore */
mtex->texco = 0;
continue;
}
/* strip all mapto flags except color and alpha */
mtex->mapto = mtex->mapto & (MAP_TRANSMISSION_COL | MAP_REFLECTION_COL | MAP_DENSITY);
}
/* if mapped to an object, calculate inverse matrices */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->texco==TEXCO_OBJECT) {
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
Object *ob= mtex->object;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (ob) {
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
invert_m4_m4(ob->imat, ob->obmat);
copy_m4_m4(ob->imat_ren, ob->imat);
}
}
/* copy texture */
Fix T37359: Dynamic Paint deletes inactive texture from smoke domain when using a material as brush color
2013-11-22 15:25:19 +02:00
tex= mtex->tex = localize_texture(cur_tex);
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
/* update texture anims */
code cleanup: BKE_scene api naming. also stop numpy from being found in /usr/include with cmake.
2012-05-05 14:33:36 +00:00
BKE_animsys_evaluate_animdata(scene, &tex->id, tex->adt, BKE_scene_frame_get(scene), ADT_RECALC_ANIM);
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
/* update texture cache if required */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->type==TEX_VOXELDATA) {
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
cache_voxeldata(tex, (int)scene->r.cfra);
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tex->type==TEX_POINTDENSITY) {
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
/* set dummy values for render and do cache */
code cleanup: use NULL rather then zero for pointers
2013-08-07 03:30:23 +00:00
Render dummy_re = {NULL};
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
dummy_re.scene = scene;
unit_m4(dummy_re.viewinv);
unit_m4(dummy_re.viewmat);
unit_m4(dummy_re.winmat);
dummy_re.winx = dummy_re.winy = 128;
cache_pointdensity(&dummy_re, tex);
}
/* update image sequences and movies */
Code Cleanup: replace checks for ima->source with BKE_image_is_animated
2014-01-14 04:59:58 +11:00
if (tex->ima && BKE_image_is_animated(tex->ima)) {
Fix #31352: Image sequence texture - can't load image after changing image source Added new flag to Imageuser which indicates whether user frame calculation is needed. This flag is getting set in BKE_image_signal and handled in actual image usage areas where both image user and current frame is known.
2012-06-04 10:41:18 +00:00
BKE_image_user_check_frame_calc(&tex->iuser, (int)scene->r.cfra, 0);
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
}
}
}
return mat;
}
/* free all duplicate data allocated by RE_init_sample_material() */
void RE_free_sample_material(Material *mat)
{
int tex_nr;
/* free textures */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
for (tex_nr=0; tex_nr<MAX_MTEX; tex_nr++) {
if (mat->septex & (1<<tex_nr)) continue;
if (mat->mtex[tex_nr]) {
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
MTex *mtex= mat->mtex[tex_nr];
Fix #30413: dynamic paint crash with texture slots with no texture assigned.
2012-03-01 20:41:13 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (mtex->tex) {
code cleanup: function naming, use BKE_*type* prefix.
2012-05-05 14:03:12 +00:00
BKE_texture_free(mtex->tex);
Fix #30413: dynamic paint crash with texture slots with no texture assigned.
2012-03-01 20:41:13 +00:00
MEM_freeN(mtex->tex);
mtex->tex = NULL;
}
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
}
}
Fix T37359: Dynamic Paint deletes inactive texture from smoke domain when using a material as brush color
2013-11-22 15:25:19 +02:00
/* don't update user counts as we are freeing a duplicate */
BKE_material_free_ex(mat, false);
Dynamic Paint: * Fixed a memory leak from previous commit.
2011-10-22 17:15:32 +00:00
MEM_freeN(mat);
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
}
/*
style cleanup: comment blocks
2012-03-09 18:28:30 +00:00
* Get material diffuse color and alpha (including linked textures) in given coordinates
*
* color,alpha : input/output color values
* volume_co : sample coordinate in global space. used by volumetric materials
* surface_co : sample surface coordinate in global space. used by "surface" materials
* face_index : surface face index
* hit_quad : whether point is on second "half" of a quad
* orcoDm : orco state derived mesh
*/
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
void RE_sample_material_color(Material *mat, float color[3], float *alpha, const float volume_co[3], const float surface_co[3], int face_index, short hit_quad, DerivedMesh *orcoDm, Object *ob)
{
MFace *mface;
int v1, v2, v3;
MVert *mvert;
float uv[3], normal[3];
code cleanup: use NULL rather then zero for pointers
2013-08-07 03:30:23 +00:00
ShadeInput shi = {NULL};
Render re = {NULL};
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
/* Get face data */
mvert = orcoDm->getVertArray(orcoDm);
bmesh compiles again after dynamic paint merge
2011-11-11 11:20:46 +00:00
mface = orcoDm->getTessFaceArray(orcoDm);
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
if (!mvert || !mface || !mat) return;
v1=mface[face_index].v1, v2=mface[face_index].v2, v3=mface[face_index].v3;
style cleanup
2012-06-25 07:24:48 +00:00
if (hit_quad) { v2 = mface[face_index].v3; v3 = mface[face_index].v4; }
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
normal_tri_v3(normal, mvert[v1].co, mvert[v2].co, mvert[v3].co);
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
/* generate shadeinput with data required */
shi.mat = mat;
/* fill shadeinput data depending on material type */
if (mat->material_type == MA_TYPE_SURFACE) {
/* global coordinates */
Merge with trunk r41701
2011-11-09 15:46:53 +00:00
copy_v3_v3(shi.gl, surface_co);
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
/* object space coordinates */
Merge with trunk r41701
2011-11-09 15:46:53 +00:00
copy_v3_v3(shi.co, surface_co);
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
mul_m4_v3(ob->imat, shi.co);
/* orco coordinates */
{
float l;
/* Get generated UV */
textured_face_generate_uv(uv, normal, shi.co, mvert[v1].co, mvert[v2].co, mvert[v3].co);
l= 1.0f+uv[0]+uv[1];
/* calculate generated coordinate */
shi.lo[0]= l*mvert[v3].co[0]-uv[0]*mvert[v1].co[0]-uv[1]*mvert[v2].co[0];
shi.lo[1]= l*mvert[v3].co[1]-uv[0]*mvert[v1].co[1]-uv[1]*mvert[v2].co[1];
shi.lo[2]= l*mvert[v3].co[2]-uv[0]*mvert[v1].co[2]-uv[1]*mvert[v2].co[2];
}
/* uv coordinates */
{
int i, layers = CustomData_number_of_layers(&orcoDm->faceData, CD_MTFACE);
int layer_index = CustomData_get_layer_index(&orcoDm->faceData, CD_MTFACE);
Patch #29336: renaming UV (Texture) Layer to UV Map in the user interface, by Gaia Clary. Rationale: the name was confusing and not always used consistently, and this map itself is not something that can be layered, rather the map can be used as texture coordinates in some layered setup. The original intent was to indicate this contained more than just UV's, but the game engine settings have already been moved out, and apparently users didn't really get this from the name anyway.
2011-11-23 17:25:25 +00:00
/* for every uv map set coords and name */
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
for (i=0; i<layers; i++) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (layer_index >= 0) {
Code cleanup: use 'const' for arrays (render)
2014-04-27 00:22:07 +10:00
const float *uv1, *uv2, *uv3;
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
float l;
CustomData *data = &orcoDm->faceData;
style cleanup
2012-07-29 00:20:28 +00:00
MTFace *tface = (MTFace *) data->layers[layer_index+i].data;
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
float uv[3];
/* point layer name from actual layer data */
shi.uv[i].name = data->layers[i].name;
/* Get generated coordinates to calculate UV from */
textured_face_generate_uv(uv, normal, shi.co, mvert[v1].co, mvert[v2].co, mvert[v3].co);
/* Get UV mapping coordinate */
l= 1.0f+uv[0]+uv[1];
uv1= tface[face_index].uv[0];
uv2= (hit_quad) ? tface[face_index].uv[2] : tface[face_index].uv[1];
uv3= (hit_quad) ? tface[face_index].uv[3] : tface[face_index].uv[2];
shi.uv[i].uv[0]= -1.0f + 2.0f*(l*uv3[0]-uv[0]*uv1[0]-uv[1]*uv2[0]);
shi.uv[i].uv[1]= -1.0f + 2.0f*(l*uv3[1]-uv[0]*uv1[1]-uv[1]*uv2[1]);
shi.uv[i].uv[2]= 0.0f; /* texture.c assumes there are 3 coords */
}
}
Patch #29336: renaming UV (Texture) Layer to UV Map in the user interface, by Gaia Clary. Rationale: the name was confusing and not always used consistently, and this map itself is not something that can be layered, rather the map can be used as texture coordinates in some layered setup. The original intent was to indicate this contained more than just UV's, but the game engine settings have already been moved out, and apparently users didn't really get this from the name anyway.
2011-11-23 17:25:25 +00:00
/* active uv map */
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
shi.actuv = CustomData_get_active_layer_index(&orcoDm->faceData, CD_MTFACE) - layer_index;
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
shi.totuv = layers;
}
/* apply initial values from material */
shi.r = mat->r;
shi.g = mat->g;
shi.b = mat->b;
shi.alpha = mat->alpha;
/* do texture */
Dynamic Paint: * Redesigned alpha blending and paint drying algorithms. Now it gives much better results when using low brush alpha or when surface has initial color set. * Fix: "Slow" dissolve/dry was scaled incorrect when using substeps. Also adjusted time to better match non-"slow" setting. * Fixed possible issues when using image textured brush. * Fix: particle brush panel was no longer visible since last commit. * Adjusted default surface values. * Some more code cleanup.
2011-10-31 13:01:06 +00:00
do_material_tex(&shi, &re);
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
/* apply result */
color[0] = shi.r;
color[1] = shi.g;
color[2] = shi.b;
*alpha = shi.alpha;
}
else if (mat->material_type == MA_TYPE_VOLUME) {
code cleanup: use NULL rather then zero for pointers
2013-08-07 03:30:23 +00:00
ObjectInstanceRen obi = {NULL};
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
obi.ob = ob;
shi.obi = &obi;
unit_m4(re.viewinv);
quiet -Wdouble-promotion warnings
2011-11-11 12:00:08 +00:00
copy_v3_v3(color, mat->vol.reflection_col);
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +00:00
*alpha = mat->vol.density;
/* do texture */
do_volume_tex(&shi, volume_co, (MAP_TRANSMISSION_COL | MAP_REFLECTION_COL | MAP_DENSITY),
quiet -Wdouble-promotion warnings
2011-11-11 12:00:08 +00:00
color, alpha, &re);
Dynamic Paint: * Some changes and cleanup pointed on the codereview.
2011-10-22 16:16:14 +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
/* eof */
Copy Permalink