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
c492729b3a0d52ae01ee67e5ad92bdb02f6585df
blender-archive/source/blender/render/intern/source/renderdatabase.c

438 lines
11 KiB
C
Raw Normal View History

Initial revision
2002-10-12 11:37:38 +00:00
/**
* $Id$
*
* ***** BEGIN GPL/BL DUAL LICENSE BLOCK *****
*
* 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
* of the License, or (at your option) any later version. The Blender
* Foundation also sells licenses for use in proprietary software under
* the Blender License. See http://www.blender.org/BL/ for information
* about this.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
* All rights reserved.
*
* The Original Code is: all of this file.
*
* Contributor(s): none yet.
*
* ***** END GPL/BL DUAL LICENSE BLOCK *****
* Storage, retrieval and query of render specific data.
*/
/*
* All data from a Blender scene is converter by the renderconverter/
* into a special format that is used by the render module to make
* images out of. These functions interface to the render-specific
* database.
*
* The blo{ha/ve/vl} arrays store pointers to blocks of 256 data
* entries each.
*
* The index of an entry is >>8 (the highest 24 * bits), to find an
* offset in a 256-entry block.
*
* - If the 256-entry block entry has an entry in the
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
* vertnodes/bloha/blovl array of the current block, the i-th entry in
Initial revision
2002-10-12 11:37:38 +00:00
* that block is allocated to this entry.
*
* - If the entry has no block allocated for it yet, memory is
* allocated.
*
* The pointer to the correct entry is returned. Memory is guarateed
* to exist (as long as the malloc does not break). Since guarded
* allocation is used, memory _must_ be available. Otherwise, an
* exit(0) would occur.
*
*/
#include <math.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 <string.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
Initial revision
2002-10-12 11:37:38 +00:00
#include "MEM_guardedalloc.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 "BKE_utildefines.h"
Initial revision
2002-10-12 11:37:38 +00:00
#include "BLI_arithb.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 "DNA_material_types.h"
- renderer currently uses links into tface structures that actually are owned by mesh (or displistmesh)... this causes problems for adapting to systems that build tfaces on the fly. Added RE_findTFace function to allow allocating tfaces inside renderer itself.
2005-03-28 19:43:45 +00:00
#include "DNA_mesh_types.h"
Initial revision
2002-10-12 11:37:38 +00:00
#include "DNA_texture_types.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
Initial revision
2002-10-12 11:37:38 +00:00
#include "BKE_texture.h"
#include "render.h"
updated .c files to include: #ifdef HAVE_CONFIG_H #include <config.h> #endif Just need to finish cpp files now :) Kent -- mein@cs.umn.edu
2002-11-25 12:02:15 +00:00
Initial revision
2002-10-12 11:37:38 +00:00
/* ------------------------------------------------------------------------- */
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
/* More dynamic allocation of options for render vertices, so we dont
have to reserve this space inside vertices.
Important; vertices should have been created already (to get tables checked)
that's a reason why the calls demand VertRen * as arg, not the index */
/* NOTE! the hardcoded table size 256 is used still in code for going quickly over vertices/faces */
#define RE_STICKY_ELEMS 2
#define RE_STRESS_ELEMS 1
#define RE_RAD_ELEMS 4
#define RE_STRAND_ELEMS 1
#define RE_TANGENT_ELEMS 3
#define RE_STRESS_ELEMS 1
/* render allocates totvert/256 of these nodes, for lookup and quick alloc */
Added Copy/Paste 'mapping' options for World/Lamp buttons. Also: moved render defines from scene to render module itself.
2005-12-03 12:55:35 +00:00
typedef struct VertTableNode {
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
struct VertRen *vert;
Added Copy/Paste 'mapping' options for World/Lamp buttons. Also: moved render defines from scene to render module itself.
2005-12-03 12:55:35 +00:00
float *rad;
float *sticky;
float *strand;
float *tangent;
float *stress;
} VertTableNode;
float *RE_vertren_get_sticky(VertRen *ver, int verify)
{
float *sticky;
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
int nr= ver->index>>8;
Added Copy/Paste 'mapping' options for World/Lamp buttons. Also: moved render defines from scene to render module itself.
2005-12-03 12:55:35 +00:00
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
sticky= R.vertnodes[nr].sticky;
Added Copy/Paste 'mapping' options for World/Lamp buttons. Also: moved render defines from scene to render module itself.
2005-12-03 12:55:35 +00:00
if(sticky==NULL) {
if(verify)
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
sticky= R.vertnodes[nr].sticky= MEM_mallocN(256*RE_STICKY_ELEMS*sizeof(float), "sticky table");
else
return NULL;
}
return sticky + (ver->index & 255)*RE_STICKY_ELEMS;
}
float *RE_vertren_get_stress(VertRen *ver, int verify)
{
float *stress;
int nr= ver->index>>8;
stress= R.vertnodes[nr].stress;
if(stress==NULL) {
if(verify)
stress= R.vertnodes[nr].stress= MEM_mallocN(256*RE_STRESS_ELEMS*sizeof(float), "stress table");
else
return NULL;
}
return stress + (ver->index & 255)*RE_STRESS_ELEMS;
}
/* this one callocs! */
float *RE_vertren_get_rad(VertRen *ver, int verify)
{
float *rad;
int nr= ver->index>>8;
rad= R.vertnodes[nr].rad;
if(rad==NULL) {
if(verify)
rad= R.vertnodes[nr].rad= MEM_callocN(256*RE_RAD_ELEMS*sizeof(float), "rad table");
else
return NULL;
}
return rad + (ver->index & 255)*RE_RAD_ELEMS;
}
float *RE_vertren_get_strand(VertRen *ver, int verify)
{
float *strand;
int nr= ver->index>>8;
strand= R.vertnodes[nr].strand;
if(strand==NULL) {
if(verify)
strand= R.vertnodes[nr].strand= MEM_mallocN(256*RE_STRAND_ELEMS*sizeof(float), "strand table");
Added Copy/Paste 'mapping' options for World/Lamp buttons. Also: moved render defines from scene to render module itself.
2005-12-03 12:55:35 +00:00
else
return NULL;
}
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
return strand + (ver->index & 255)*RE_STRAND_ELEMS;
Added Copy/Paste 'mapping' options for World/Lamp buttons. Also: moved render defines from scene to render module itself.
2005-12-03 12:55:35 +00:00
}
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
float *RE_vertren_get_tangent(VertRen *ver, int verify)
{
float *tangent;
int nr= ver->index>>8;
tangent= R.vertnodes[nr].tangent;
if(tangent==NULL) {
if(verify)
tangent= R.vertnodes[nr].tangent= MEM_mallocN(256*RE_TANGENT_ELEMS*sizeof(float), "tangent table");
else
return NULL;
}
return tangent + (ver->index & 255)*RE_TANGENT_ELEMS;
}
Added Copy/Paste 'mapping' options for World/Lamp buttons. Also: moved render defines from scene to render module itself.
2005-12-03 12:55:35 +00:00
Initial revision
2002-10-12 11:37:38 +00:00
VertRen *RE_findOrAddVert(int nr)
{
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
VertTableNode *temp;
VertRen *v;
static int rvertnodeslen=TABLEINITSIZE;
Initial revision
2002-10-12 11:37:38 +00:00
int a;
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
if(nr<0) {
Initial revision
2002-10-12 11:37:38 +00:00
printf("error in findOrAddVert: %d\n",nr);
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
return R.vertnodes[0].vert;
Initial revision
2002-10-12 11:37:38 +00:00
}
a= nr>>8;
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
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
if (a>=rvertnodeslen-1){ /* Need to allocate more columns..., and keep last element NULL for free loop */
temp= R.vertnodes;
R.vertnodes= MEM_mallocN(sizeof(VertTableNode)*(rvertnodeslen+TABLEINITSIZE) , "vertnodes");
memcpy(R.vertnodes, temp, rvertnodeslen*sizeof(VertTableNode));
memset(R.vertnodes+rvertnodeslen, 0, TABLEINITSIZE*sizeof(VertTableNode));
rvertnodeslen+=TABLEINITSIZE;
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
MEM_freeN(temp);
}
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
v= R.vertnodes[a].vert;
if(v==NULL) {
int i;
Initial revision
2002-10-12 11:37:38 +00:00
v= (VertRen *)MEM_callocN(256*sizeof(VertRen),"findOrAddVert");
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
R.vertnodes[a].vert= v;
for(i= (nr & 0xFFFFFF00), a=0; a<256; a++, i++) {
v[a].index= i;
}
Initial revision
2002-10-12 11:37:38 +00:00
}
v+= (nr & 255);
return v;
}
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
void RE_free_vertex_tables(void)
{
int a=0;
while(R.vertnodes[a].vert) {
if(R.vertnodes[a].vert) {
MEM_freeN(R.vertnodes[a].vert);
R.vertnodes[a].vert= NULL;
if(R.vertnodes[a].rad) {
MEM_freeN(R.vertnodes[a].rad);
R.vertnodes[a].rad= NULL;
}
if(R.vertnodes[a].sticky) {
MEM_freeN(R.vertnodes[a].sticky);
R.vertnodes[a].sticky= NULL;
}
if(R.vertnodes[a].strand) {
MEM_freeN(R.vertnodes[a].strand);
R.vertnodes[a].strand= NULL;
}
if(R.vertnodes[a].tangent) {
MEM_freeN(R.vertnodes[a].tangent);
R.vertnodes[a].tangent= NULL;
}
if(R.vertnodes[a].stress) {
MEM_freeN(R.vertnodes[a].stress);
R.vertnodes[a].stress= NULL;
}
}
a++;
}
}
/* only once, on startup */
void RE_init_vertex_tables(void)
{
R.vertnodes= MEM_callocN(sizeof(VertTableNode)*TABLEINITSIZE , "vertnodes");
}
Initial revision
2002-10-12 11:37:38 +00:00
/* ------------------------------------------------------------------------ */
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
int rblohalen=TABLEINITSIZE;
Initial revision
2002-10-12 11:37:38 +00:00
HaloRen *RE_findOrAddHalo(int nr)
{
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
HaloRen *h, **temp;
Initial revision
2002-10-12 11:37:38 +00:00
int a;
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
if(nr<0) {
Initial revision
2002-10-12 11:37:38 +00:00
printf("error in findOrAddHalo: %d\n",nr);
return R.bloha[0];
}
a= nr>>8;
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
Bug fix, provided by Martin Dickopp; The dynamical allocated arrays (rwenzlaff, april 03) for render vertices/ faces/halos were freed in a way that requires the last element of array to be NULL. This wasn't coded however, causing memory errors in exceptional cases; like when amount of faces/vertices is exact between 261888 and 262144. :)
2005-03-04 22:17:52 +00:00
if (a>=rblohalen-1){ /* Need to allocate more columns..., and keep last element NULL for free loop */
Solved AO smooth rendering, by introducing a "Bias" value for smoothed rendered faces. http://www.blender3d.org/cms/Ambient_Occlusion.231.0.html ALso removed prints when allocating new 'face groups' etc, which wasn't informative at all.
2004-04-26 14:17:48 +00:00
//printf("Allocating %i more halo groups. %i total.\n",
// TABLEINITSIZE, rblohalen+TABLEINITSIZE );
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
temp=R.bloha;
Bug fix, provided by Martin Dickopp; The dynamical allocated arrays (rwenzlaff, april 03) for render vertices/ faces/halos were freed in a way that requires the last element of array to be NULL. This wasn't coded however, causing memory errors in exceptional cases; like when amount of faces/vertices is exact between 261888 and 262144. :)
2005-03-04 22:17:52 +00:00
R.bloha=(HaloRen**)MEM_callocN(sizeof(void*)*(rblohalen+TABLEINITSIZE) , "Bloha");
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
memcpy(R.bloha, temp, rblohalen*sizeof(void*));
Bug fix, provided by Martin Dickopp; The dynamical allocated arrays (rwenzlaff, april 03) for render vertices/ faces/halos were freed in a way that requires the last element of array to be NULL. This wasn't coded however, causing memory errors in exceptional cases; like when amount of faces/vertices is exact between 261888 and 262144. :)
2005-03-04 22:17:52 +00:00
memset(&(R.bloha[rblohalen]), 0, TABLEINITSIZE*sizeof(void*));
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
rblohalen+=TABLEINITSIZE; /*Does this really need to be power of 2?*/
MEM_freeN(temp);
}
Initial revision
2002-10-12 11:37:38 +00:00
h= R.bloha[a];
if(h==0) {
h= (HaloRen *)MEM_callocN(256*sizeof(HaloRen),"findOrAdHalo");
R.bloha[a]= h;
}
h+= (nr & 255);
return h;
}
/* ------------------------------------------------------------------------ */
VlakRen *RE_findOrAddVlak(int nr)
{
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
VlakRen *v, **temp;
static int rblovllen=TABLEINITSIZE;
Initial revision
2002-10-12 11:37:38 +00:00
int a;
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
if(nr<0) {
Initial revision
2002-10-12 11:37:38 +00:00
printf("error in findOrAddVlak: %d\n",nr);
return R.blovl[0];
}
a= nr>>8;
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
Bug fix, provided by Martin Dickopp; The dynamical allocated arrays (rwenzlaff, april 03) for render vertices/ faces/halos were freed in a way that requires the last element of array to be NULL. This wasn't coded however, causing memory errors in exceptional cases; like when amount of faces/vertices is exact between 261888 and 262144. :)
2005-03-04 22:17:52 +00:00
if (a>=rblovllen-1){ /* Need to allocate more columns..., and keep last element NULL for free loop */
Solved AO smooth rendering, by introducing a "Bias" value for smoothed rendered faces. http://www.blender3d.org/cms/Ambient_Occlusion.231.0.html ALso removed prints when allocating new 'face groups' etc, which wasn't informative at all.
2004-04-26 14:17:48 +00:00
// printf("Allocating %i more face groups. %i total.\n",
// TABLEINITSIZE, rblovllen+TABLEINITSIZE );
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
temp=R.blovl;
Bug fix, provided by Martin Dickopp; The dynamical allocated arrays (rwenzlaff, april 03) for render vertices/ faces/halos were freed in a way that requires the last element of array to be NULL. This wasn't coded however, causing memory errors in exceptional cases; like when amount of faces/vertices is exact between 261888 and 262144. :)
2005-03-04 22:17:52 +00:00
R.blovl=(VlakRen**)MEM_callocN(sizeof(void*)*(rblovllen+TABLEINITSIZE) , "Blovl");
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
memcpy(R.blovl, temp, rblovllen*sizeof(void*));
Bug fix, provided by Martin Dickopp; The dynamical allocated arrays (rwenzlaff, april 03) for render vertices/ faces/halos were freed in a way that requires the last element of array to be NULL. This wasn't coded however, causing memory errors in exceptional cases; like when amount of faces/vertices is exact between 261888 and 262144. :)
2005-03-04 22:17:52 +00:00
memset(&(R.blovl[rblovllen]), 0, TABLEINITSIZE*sizeof(void*));
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
rblovllen+=TABLEINITSIZE; /*Does this really need to be power of 2?*/
MEM_freeN(temp);
}
Initial revision
2002-10-12 11:37:38 +00:00
v= R.blovl[a];
Dynamic Face/Vert/Halo/Lamp tables: User Info: Hard coded limits on the total number of face, verts, halos, and lamps is gone. Blender now allocates the tables for these on an as needed basis. As long as your system can come up with the memory, you won't run out. As a bonus, it also uses slightly less memory on smaller scenes. Coder info: This has been in tuhopuu for a while, but I don't know how hard it has been tested. Since it now allocates only an initial 1024 tables (of 256 verts/faces/halos each), it seems like it has been put through it's paces. Lamps are allocated one at a time, and I start with 256. I rendered 2.5M Faces/Verts/Halos. 4444 lamps. None the less, I left a few printf's in the realocation to hunt bugs. I'll take them out just before the release freeze. Also, be on the lookout for other "sanity checks" that assume a limited number of the above items. I think I got them all, but you never know.
2003-10-19 21:47:03 +00:00
Initial revision
2002-10-12 11:37:38 +00:00
if(v==0) {
v= (VlakRen *)MEM_callocN(256*sizeof(VlakRen),"findOrAddVlak");
R.blovl[a]= v;
}
v+= (nr & 255);
return v;
}
/* ------------------------------------------------------------------------- */
Biiig commit! Thanks to 2-3 weeks of cvs freeze... Render: - New; support for dual CPU render (SDL thread) Currently only works with alternating scanlines, but gives excellent performance. For both normal render as unified implemented. Note the "mutex" locks on z-transp buffer render and imbuf loads. - This has been made possible by major cleanups in render code, especially getting rid of globals (example Tin Tr Tg Tb Ta for textures) or struct OSA or using Materials or Texture data to write to. - Made normal render fully 4x32 floats too, and removed all old optimizes with chars or shorts. - Made normal render and unified render use same code for sky and halo render, giving equal (and better) results for halo render. Old render now also uses PostProcess options (brightness, mul, gamma) - Added option ("FBuf") in F10 Output Panel, this keeps a 4x32 bits buffer after render. Using PostProcess menu you will note an immediate re- display of image too (32 bits RGBA) - Added "Hue" and "Saturation" sliders to PostProcess options - Render module is still not having a "nice" API, but amount of dependencies went down a lot. Next todo: remove abusive "previewrender" code. The last main global in Render (struct Render) now can be re-used for fully controlling a render, to allow multiple "instances" of render to open. - Renderwindow now displays a smal bar on top with the stats, and keeps the stats after render too. Including "spare" page support. Not only easier visible that way, but also to remove the awkward code that was drawing stats in the Info header (extreme slow on some ATIs too) - Cleaned up blendef.h and BKE_utildefines.h, these two had overlapping defines. - I might have forgotten stuff... and will write a nice doc on the architecture!
2004-12-27 19:28:52 +00:00
HaloRen *RE_inithalo(Material *ma, float *vec, float *vec1,
float *orco, float hasize, float vectsize, int seed)
Initial revision
2002-10-12 11:37:38 +00:00
{
HaloRen *har;
MTex *mtex;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... Render: - New; support for dual CPU render (SDL thread) Currently only works with alternating scanlines, but gives excellent performance. For both normal render as unified implemented. Note the "mutex" locks on z-transp buffer render and imbuf loads. - This has been made possible by major cleanups in render code, especially getting rid of globals (example Tin Tr Tg Tb Ta for textures) or struct OSA or using Materials or Texture data to write to. - Made normal render fully 4x32 floats too, and removed all old optimizes with chars or shorts. - Made normal render and unified render use same code for sky and halo render, giving equal (and better) results for halo render. Old render now also uses PostProcess options (brightness, mul, gamma) - Added option ("FBuf") in F10 Output Panel, this keeps a 4x32 bits buffer after render. Using PostProcess menu you will note an immediate re- display of image too (32 bits RGBA) - Added "Hue" and "Saturation" sliders to PostProcess options - Render module is still not having a "nice" API, but amount of dependencies went down a lot. Next todo: remove abusive "previewrender" code. The last main global in Render (struct Render) now can be re-used for fully controlling a render, to allow multiple "instances" of render to open. - Renderwindow now displays a smal bar on top with the stats, and keeps the stats after render too. Including "spare" page support. Not only easier visible that way, but also to remove the awkward code that was drawing stats in the Info header (extreme slow on some ATIs too) - Cleaned up blendef.h and BKE_utildefines.h, these two had overlapping defines. - I might have forgotten stuff... and will write a nice doc on the architecture!
2004-12-27 19:28:52 +00:00
float tin, tr, tg, tb, ta;
Initial revision
2002-10-12 11:37:38 +00:00
float xn, yn, zn, texvec[3], hoco[4], hoco1[4];
Another round of cleanups for render code; - removed ugly pointerhack from OSA render (negative indices denoted pointers). this should solve memory errors when using >1.5 gig mem - cleaned up usage of zbuffer values. These are signed in Blender, and treated as unsigned all over, giving confusing code - fixed incorrect gamma-adding for halos (caused in after xmas commit) And bugfix #2101; wire render didn't give correct rendering for mist. This caused by fact wires are 2D pixel lines, and not correctly filled in faces. Retrieving the 3d coordinate while render cannot use a face- equation then. Solved by retrieving 3D coordinate based on zbuffer value. Still todo here: calculating correct texture coordinates for wire-edges that are no faces.
2005-01-07 14:11:00 +00:00
if(hasize==0.0) return NULL;
Initial revision
2002-10-12 11:37:38 +00:00
RE_projectverto(vec, hoco);
Another round of cleanups for render code; - removed ugly pointerhack from OSA render (negative indices denoted pointers). this should solve memory errors when using >1.5 gig mem - cleaned up usage of zbuffer values. These are signed in Blender, and treated as unsigned all over, giving confusing code - fixed incorrect gamma-adding for halos (caused in after xmas commit) And bugfix #2101; wire render didn't give correct rendering for mist. This caused by fact wires are 2D pixel lines, and not correctly filled in faces. Retrieving the 3d coordinate while render cannot use a face- equation then. Solved by retrieving 3D coordinate based on zbuffer value. Still todo here: calculating correct texture coordinates for wire-edges that are no faces.
2005-01-07 14:11:00 +00:00
if(hoco[3]==0.0) return NULL;
Initial revision
2002-10-12 11:37:38 +00:00
if(vec1) {
RE_projectverto(vec1, hoco1);
Another round of cleanups for render code; - removed ugly pointerhack from OSA render (negative indices denoted pointers). this should solve memory errors when using >1.5 gig mem - cleaned up usage of zbuffer values. These are signed in Blender, and treated as unsigned all over, giving confusing code - fixed incorrect gamma-adding for halos (caused in after xmas commit) And bugfix #2101; wire render didn't give correct rendering for mist. This caused by fact wires are 2D pixel lines, and not correctly filled in faces. Retrieving the 3d coordinate while render cannot use a face- equation then. Solved by retrieving 3D coordinate based on zbuffer value. Still todo here: calculating correct texture coordinates for wire-edges that are no faces.
2005-01-07 14:11:00 +00:00
if(hoco1[3]==0.0) return NULL;
Initial revision
2002-10-12 11:37:38 +00:00
}
har= RE_findOrAddHalo(R.tothalo++);
VECCOPY(har->co, vec);
har->hasize= hasize;
Another round of cleanups for render code; - removed ugly pointerhack from OSA render (negative indices denoted pointers). this should solve memory errors when using >1.5 gig mem - cleaned up usage of zbuffer values. These are signed in Blender, and treated as unsigned all over, giving confusing code - fixed incorrect gamma-adding for halos (caused in after xmas commit) And bugfix #2101; wire render didn't give correct rendering for mist. This caused by fact wires are 2D pixel lines, and not correctly filled in faces. Retrieving the 3d coordinate while render cannot use a face- equation then. Solved by retrieving 3D coordinate based on zbuffer value. Still todo here: calculating correct texture coordinates for wire-edges that are no faces.
2005-01-07 14:11:00 +00:00
/* projectvert is done in function 'zbufvlaggen' because of parts/border/pano */
Initial revision
2002-10-12 11:37:38 +00:00
/* halovect */
if(vec1) {
har->type |= HA_VECT;
zn= hoco[3];
har->xs= 0.5*R.rectx*(hoco[0]/zn);
har->ys= 0.5*R.recty*(hoco[1]/zn);
Another round of cleanups for render code; - removed ugly pointerhack from OSA render (negative indices denoted pointers). this should solve memory errors when using >1.5 gig mem - cleaned up usage of zbuffer values. These are signed in Blender, and treated as unsigned all over, giving confusing code - fixed incorrect gamma-adding for halos (caused in after xmas commit) And bugfix #2101; wire render didn't give correct rendering for mist. This caused by fact wires are 2D pixel lines, and not correctly filled in faces. Retrieving the 3d coordinate while render cannot use a face- equation then. Solved by retrieving 3D coordinate based on zbuffer value. Still todo here: calculating correct texture coordinates for wire-edges that are no faces.
2005-01-07 14:11:00 +00:00
har->zs= 0x7FFFFF*(hoco[2]/zn);
Initial revision
2002-10-12 11:37:38 +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
har->zBufDist = 0x7FFFFFFF*(hoco[2]/zn);
Initial revision
2002-10-12 11:37:38 +00:00
xn= har->xs - 0.5*R.rectx*(hoco1[0]/hoco1[3]);
yn= har->ys - 0.5*R.recty*(hoco1[1]/hoco1[3]);
if(xn==0.0 || (xn==0.0 && yn==0.0)) zn= 0.0;
else zn= atan2(yn, xn);
har->sin= sin(zn);
har->cos= cos(zn);
zn= VecLenf(vec1, vec);
har->hasize= vectsize*zn + (1.0-vectsize)*hasize;
VecSubf(har->no, vec, vec1);
Normalise(har->no);
}
if(ma->mode & MA_HALO_XALPHA) har->type |= HA_XALPHA;
har->alfa= ma->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
har->r= ma->r;
har->g= ma->g;
har->b= ma->b;
har->add= (255.0*ma->add);
har->mat= ma;
Initial revision
2002-10-12 11:37:38 +00:00
har->hard= ma->har;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... Render: - New; support for dual CPU render (SDL thread) Currently only works with alternating scanlines, but gives excellent performance. For both normal render as unified implemented. Note the "mutex" locks on z-transp buffer render and imbuf loads. - This has been made possible by major cleanups in render code, especially getting rid of globals (example Tin Tr Tg Tb Ta for textures) or struct OSA or using Materials or Texture data to write to. - Made normal render fully 4x32 floats too, and removed all old optimizes with chars or shorts. - Made normal render and unified render use same code for sky and halo render, giving equal (and better) results for halo render. Old render now also uses PostProcess options (brightness, mul, gamma) - Added option ("FBuf") in F10 Output Panel, this keeps a 4x32 bits buffer after render. Using PostProcess menu you will note an immediate re- display of image too (32 bits RGBA) - Added "Hue" and "Saturation" sliders to PostProcess options - Render module is still not having a "nice" API, but amount of dependencies went down a lot. Next todo: remove abusive "previewrender" code. The last main global in Render (struct Render) now can be re-used for fully controlling a render, to allow multiple "instances" of render to open. - Renderwindow now displays a smal bar on top with the stats, and keeps the stats after render too. Including "spare" page support. Not only easier visible that way, but also to remove the awkward code that was drawing stats in the Info header (extreme slow on some ATIs too) - Cleaned up blendef.h and BKE_utildefines.h, these two had overlapping defines. - I might have forgotten stuff... and will write a nice doc on the architecture!
2004-12-27 19:28:52 +00:00
har->seed= seed % 256;
Initial revision
2002-10-12 11:37:38 +00:00
if(ma->mode & MA_STAR) har->starpoints= ma->starc;
if(ma->mode & MA_HALO_LINES) har->linec= ma->linec;
if(ma->mode & MA_HALO_RINGS) har->ringc= ma->ringc;
if(ma->mode & MA_HALO_FLARE) har->flarec= ma->flarec;
if(ma->mtex[0]) {
if( (ma->mode & MA_HALOTEX) ) har->tex= 1;
else {
mtex= ma->mtex[0];
VECCOPY(texvec, vec);
if(mtex->texco & TEXCO_NORM) {
;
}
else if(mtex->texco & TEXCO_OBJECT) {
/* texvec[0]+= imatbase->ivec[0]; */
/* texvec[1]+= imatbase->ivec[1]; */
/* texvec[2]+= imatbase->ivec[2]; */
/* Mat3MulVecfl(imatbase->imat, texvec); */
}
else {
if(orco) {
VECCOPY(texvec, orco);
}
}
Biiig commit! Thanks to 2-3 weeks of cvs freeze... Render: - New; support for dual CPU render (SDL thread) Currently only works with alternating scanlines, but gives excellent performance. For both normal render as unified implemented. Note the "mutex" locks on z-transp buffer render and imbuf loads. - This has been made possible by major cleanups in render code, especially getting rid of globals (example Tin Tr Tg Tb Ta for textures) or struct OSA or using Materials or Texture data to write to. - Made normal render fully 4x32 floats too, and removed all old optimizes with chars or shorts. - Made normal render and unified render use same code for sky and halo render, giving equal (and better) results for halo render. Old render now also uses PostProcess options (brightness, mul, gamma) - Added option ("FBuf") in F10 Output Panel, this keeps a 4x32 bits buffer after render. Using PostProcess menu you will note an immediate re- display of image too (32 bits RGBA) - Added "Hue" and "Saturation" sliders to PostProcess options - Render module is still not having a "nice" API, but amount of dependencies went down a lot. Next todo: remove abusive "previewrender" code. The last main global in Render (struct Render) now can be re-used for fully controlling a render, to allow multiple "instances" of render to open. - Renderwindow now displays a smal bar on top with the stats, and keeps the stats after render too. Including "spare" page support. Not only easier visible that way, but also to remove the awkward code that was drawing stats in the Info header (extreme slow on some ATIs too) - Cleaned up blendef.h and BKE_utildefines.h, these two had overlapping defines. - I might have forgotten stuff... and will write a nice doc on the architecture!
2004-12-27 19:28:52 +00:00
externtex(mtex, texvec, &tin, &tr, &tg, &tb, &ta);
Initial revision
2002-10-12 11:37:38 +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
yn= tin*mtex->colfac;
zn= tin*mtex->varfac;
Initial revision
2002-10-12 11:37:38 +00:00
if(mtex->mapto & MAP_COL) {
zn= 1.0-yn;
Biiig commit! Thanks to 2-3 weeks of cvs freeze... Render: - New; support for dual CPU render (SDL thread) Currently only works with alternating scanlines, but gives excellent performance. For both normal render as unified implemented. Note the "mutex" locks on z-transp buffer render and imbuf loads. - This has been made possible by major cleanups in render code, especially getting rid of globals (example Tin Tr Tg Tb Ta for textures) or struct OSA or using Materials or Texture data to write to. - Made normal render fully 4x32 floats too, and removed all old optimizes with chars or shorts. - Made normal render and unified render use same code for sky and halo render, giving equal (and better) results for halo render. Old render now also uses PostProcess options (brightness, mul, gamma) - Added option ("FBuf") in F10 Output Panel, this keeps a 4x32 bits buffer after render. Using PostProcess menu you will note an immediate re- display of image too (32 bits RGBA) - Added "Hue" and "Saturation" sliders to PostProcess options - Render module is still not having a "nice" API, but amount of dependencies went down a lot. Next todo: remove abusive "previewrender" code. The last main global in Render (struct Render) now can be re-used for fully controlling a render, to allow multiple "instances" of render to open. - Renderwindow now displays a smal bar on top with the stats, and keeps the stats after render too. Including "spare" page support. Not only easier visible that way, but also to remove the awkward code that was drawing stats in the Info header (extreme slow on some ATIs too) - Cleaned up blendef.h and BKE_utildefines.h, these two had overlapping defines. - I might have forgotten stuff... and will write a nice doc on the architecture!
2004-12-27 19:28:52 +00:00
har->r= (yn*tr+ zn*ma->r);
har->g= (yn*tg+ zn*ma->g);
har->b= (yn*tb+ zn*ma->b);
Initial revision
2002-10-12 11:37:38 +00:00
}
if(mtex->texco & 16) {
Biiig commit! Thanks to 2-3 weeks of cvs freeze... Render: - New; support for dual CPU render (SDL thread) Currently only works with alternating scanlines, but gives excellent performance. For both normal render as unified implemented. Note the "mutex" locks on z-transp buffer render and imbuf loads. - This has been made possible by major cleanups in render code, especially getting rid of globals (example Tin Tr Tg Tb Ta for textures) or struct OSA or using Materials or Texture data to write to. - Made normal render fully 4x32 floats too, and removed all old optimizes with chars or shorts. - Made normal render and unified render use same code for sky and halo render, giving equal (and better) results for halo render. Old render now also uses PostProcess options (brightness, mul, gamma) - Added option ("FBuf") in F10 Output Panel, this keeps a 4x32 bits buffer after render. Using PostProcess menu you will note an immediate re- display of image too (32 bits RGBA) - Added "Hue" and "Saturation" sliders to PostProcess options - Render module is still not having a "nice" API, but amount of dependencies went down a lot. Next todo: remove abusive "previewrender" code. The last main global in Render (struct Render) now can be re-used for fully controlling a render, to allow multiple "instances" of render to open. - Renderwindow now displays a smal bar on top with the stats, and keeps the stats after render too. Including "spare" page support. Not only easier visible that way, but also to remove the awkward code that was drawing stats in the Info header (extreme slow on some ATIs too) - Cleaned up blendef.h and BKE_utildefines.h, these two had overlapping defines. - I might have forgotten stuff... and will write a nice doc on the architecture!
2004-12-27 19:28:52 +00:00
har->alfa= tin;
Initial revision
2002-10-12 11:37:38 +00:00
}
}
}
return har;
}
/* ------------------------------------------------------------------------- */
Copy Permalink