2023-08-16 00:20:26 +10:00
|
|
|
/* SPDX-FileCopyrightText: 2008-2023 Blender Authors
|
2023-06-14 23:30:43 +10:00
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
2012-12-18 00:51:25 +00:00
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup freestyle
|
2012-12-18 00:51:25 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "BlenderStrokeRenderer.h"
|
|
|
|
|
|
|
|
|
|
#include "../application/AppConfig.h"
|
|
|
|
|
#include "../stroke/Canvas.h"
|
|
|
|
|
|
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
2008-12-01 21:30:44 +00:00
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
2023-08-10 22:40:27 +02:00
|
|
|
#include "RNA_access.hh"
|
2022-03-14 16:54:46 +01:00
|
|
|
#include "RNA_prototypes.h"
|
2023-08-10 22:40:27 +02:00
|
|
|
#include "RNA_types.hh"
|
2014-06-27 16:00:22 +09:00
|
|
|
|
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
2008-12-01 21:30:44 +00:00
|
|
|
#include "DNA_camera_types.h"
|
2018-08-29 15:32:50 +02:00
|
|
|
#include "DNA_collection_types.h"
|
2014-07-16 00:21:27 +09:00
|
|
|
#include "DNA_linestyle_types.h"
|
2020-03-26 01:14:08 +01:00
|
|
|
#include "DNA_listBase.h"
|
2014-06-27 00:40:41 +09:00
|
|
|
#include "DNA_material_types.h"
|
2012-12-18 00:51:25 +00:00
|
|
|
#include "DNA_mesh_types.h"
|
2020-03-26 01:14:08 +01:00
|
|
|
#include "DNA_meshdata_types.h"
|
2010-03-28 18:12:45 +00:00
|
|
|
#include "DNA_object_types.h"
|
2014-06-27 00:40:41 +09:00
|
|
|
#include "DNA_scene_types.h"
|
2020-03-26 01:14:08 +01:00
|
|
|
#include "DNA_screen_types.h"
|
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
2008-12-01 21:30:44 +00:00
|
|
|
|
2022-12-15 14:18:57 -06:00
|
|
|
#include "BKE_attribute.h"
|
2017-05-18 16:03:28 +02:00
|
|
|
#include "BKE_collection.h"
|
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
2008-12-01 21:30:44 +00:00
|
|
|
#include "BKE_customdata.h"
|
|
|
|
|
#include "BKE_global.h"
|
2020-03-26 01:14:08 +01:00
|
|
|
#include "BKE_idprop.h"
|
Collections and groups unification
OVERVIEW
* In 2.7 terminology, all layers and groups are now collection datablocks.
* These collections are nestable, linkable, instanceable, overrideable, ..
which opens up new ways to set up scenes and link + override data.
* Viewport/render visibility and selectability are now a part of the collection
and shared across all view layers and linkable.
* View layers define which subset of the scene collection hierarchy is excluded
for each. For many workflows one view layer can be used, these are more of an
advanced feature now.
OUTLINER
* The outliner now has a "View Layer" display mode instead of "Collections",
which can display the collections and/or objects in the view layer.
* In this display mode, collections can be excluded with the right click menu.
These will then be greyed out and their objects will be excluded.
* To view collections not linked to any scene, the "Blender File" display mode
can be used, with the new filtering option to just see Colleciton datablocks.
* The outliner right click menus for collections and objects were reorganized.
* Drag and drop still needs to be improved. Like before, dragging the icon or
text gives different results, we'll unify this later.
LINKING AND OVERRIDES
* Collections can now be linked into the scene without creating an instance,
with the link/append operator or from the collections view in the outliner.
* Collections can get static overrides with the right click menu in the outliner,
but this is rather unreliable and not clearly communicated at the moment.
* We still need to improve the make override operator to turn collection instances
into collections with overrides directly in the scene.
PERFORMANCE
* We tried to make performance not worse than before and improve it in some
cases. The main thing that's still a bit slower is multiple scenes, we have to
change the layer syncing to only updated affected scenes.
* Collections keep a list of their parent collections for faster incremental
updates in syncing and caching.
* View layer bases are now in a object -> base hash to avoid quadratic time
lookups internally and in API functions like visible_get().
VERSIONING
* Compatibility with 2.7 files should be improved due to the new visibility
controls. Of course users may not want to set up their scenes differently
now to avoid having separate layers and groups.
* Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero
files. There's a few things which are know to be not quite compatible, like
nested layer collections inside groups.
* The versioning code for 2.8 files is quite complicated, and isolated behind
#ifdef so it can be removed at the end of the release cycle.
KNOWN ISSUES
* The G-key group operators in the 3D viewport were left mostly as is, they
need to be modified still to fit better.
* Same for the groups panel in the object properties. This needs to be updated
still, or perhaps replaced by something better.
* Collections must all have a unique name. Less restrictive namespacing is to
be done later, we'll have to see how important this is as all objects within
the collections must also have a unique name anyway.
* Full scene copy and delete scene are exactly doing the right thing yet.
Differential Revision: https://developer.blender.org/D3383
https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
|
|
|
#include "BKE_layer.h"
|
2020-02-10 12:58:59 +01:00
|
|
|
#include "BKE_lib_id.h" /* free_libblock */
|
2022-08-20 13:42:10 +02:00
|
|
|
#include "BKE_main.h"
|
2012-12-18 00:51:25 +00:00
|
|
|
#include "BKE_material.h"
|
2023-03-12 22:29:15 +01:00
|
|
|
#include "BKE_mesh.hh"
|
2023-05-15 15:14:22 +02:00
|
|
|
#include "BKE_node.hh"
|
2021-12-21 15:18:56 +01:00
|
|
|
#include "BKE_node_tree_update.h"
|
2023-10-09 23:41:53 +02:00
|
|
|
#include "BKE_object.hh"
|
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
2008-12-01 21:30:44 +00:00
|
|
|
#include "BKE_scene.h"
|
|
|
|
|
|
2014-07-19 23:42:15 +09:00
|
|
|
#include "BLI_ghash.h"
|
2014-07-19 15:38:56 +09:00
|
|
|
#include "BLI_listbase.h"
|
2015-10-10 18:44:19 +02:00
|
|
|
#include "BLI_math_color.h"
|
|
|
|
|
#include "BLI_math_vector.h"
|
2023-01-11 13:03:49 +11:00
|
|
|
#include "BLI_math_vector_types.hh"
|
2014-05-09 11:58:25 +09:00
|
|
|
#include "BLI_utildefines.h"
|
|
|
|
|
|
2023-09-22 03:18:17 +02:00
|
|
|
#include "DEG_depsgraph.hh"
|
|
|
|
|
#include "DEG_depsgraph_build.hh"
|
2017-04-06 16:32:59 +02:00
|
|
|
|
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
2008-12-01 21:30:44 +00:00
|
|
|
#include "RE_pipeline.h"
|
2014-06-27 00:40:41 +09:00
|
|
|
|
|
|
|
|
#include "render_types.h"
|
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
2008-12-01 21:30:44 +00:00
|
|
|
|
2020-12-04 11:28:09 +01:00
|
|
|
#include <climits>
|
2014-04-24 13:57:10 +09:00
|
|
|
|
Mesh: Move positions to a generic attribute
**Changes**
As described in T93602, this patch removes all use of the `MVert`
struct, replacing it with a generic named attribute with the name
`"position"`, consistent with other geometry types.
Variable names have been changed from `verts` to `positions`, to align
with the attribute name and the more generic design (positions are not
vertices, they are just an attribute stored on the point domain).
This change is made possible by previous commits that moved all other
data out of `MVert` to runtime data or other generic attributes. What
remains is mostly a simple type change. Though, the type still shows up
859 times, so the patch is quite large.
One compromise is that now `CD_MASK_BAREMESH` now contains
`CD_PROP_FLOAT3`. With the general move towards generic attributes
over custom data types, we are removing use of these type masks anyway.
**Benefits**
The most obvious benefit is reduced memory usage and the benefits
that brings in memory-bound situations. `float3` is only 3 bytes, in
comparison to `MVert` which was 4. When there are millions of vertices
this starts to matter more.
The other benefits come from using a more generic type. Instead of
writing algorithms specifically for `MVert`, code can just use arrays
of vectors. This will allow eliminating many temporary arrays or
wrappers used to extract positions.
Many possible improvements aren't implemented in this patch, though
I did switch simplify or remove the process of creating temporary
position arrays in a few places.
The design clarity that "positions are just another attribute" brings
allows removing explicit copying of vertices in some procedural
operations-- they are just processed like most other attributes.
**Performance**
This touches so many areas that it's hard to benchmark exhaustively,
but I observed some areas as examples.
* The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster.
* The Spring splash screen went from ~4.3 to ~4.5 fps.
* The subdivision surface modifier/node was slightly faster
RNA access through Python may be slightly slower, since now we need
a name lookup instead of just a custom data type lookup for each index.
**Future Improvements**
* Remove uses of "vert_coords" functions:
* `BKE_mesh_vert_coords_alloc`
* `BKE_mesh_vert_coords_get`
* `BKE_mesh_vert_coords_apply{_with_mat4}`
* Remove more hidden copying of positions
* General simplification now possible in many areas
* Convert more code to C++ to use `float3` instead of `float[3]`
* Currently `reinterpret_cast` is used for those C-API functions
Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
|
|
|
using blender::float3;
|
|
|
|
|
|
2013-04-09 00:46:49 +00:00
|
|
|
namespace Freestyle {
|
|
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
const char *BlenderStrokeRenderer::uvNames[] = {"along_stroke", "along_stroke_tips"};
|
|
|
|
|
|
2020-08-07 15:58:58 +02:00
|
|
|
BlenderStrokeRenderer::BlenderStrokeRenderer(Render *re, int render_count)
|
2012-12-18 00:51:25 +00:00
|
|
|
{
|
2020-03-26 01:14:08 +01:00
|
|
|
freestyle_bmain = BKE_main_new();
|
|
|
|
|
|
|
|
|
|
/* We use the same window manager for freestyle bmain as
|
|
|
|
|
* real bmain uses. This is needed because freestyle's
|
|
|
|
|
* bmain could be used to tag scenes for update, which
|
|
|
|
|
* implies call of ED_render_scene_update in some cases
|
|
|
|
|
* and that function requires proper window manager
|
|
|
|
|
* to present (sergey)
|
|
|
|
|
*/
|
|
|
|
|
freestyle_bmain->wm = re->main->wm;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-12-18 00:51:25 +00:00
|
|
|
// for stroke mesh generation
|
|
|
|
|
_width = re->winx;
|
|
|
|
|
_height = re->winy;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-09-28 03:56:31 +00:00
|
|
|
old_scene = re->scene;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-06-10 10:58:49 +00:00
|
|
|
char name[MAX_ID_NAME - 2];
|
2023-05-09 12:50:37 +10:00
|
|
|
SNPRINTF(name, "FRS%d_%s", render_count, re->scene->id.name + 2);
|
2013-04-23 22:40:13 +00:00
|
|
|
freestyle_scene = BKE_scene_add(freestyle_bmain, name);
|
2011-04-17 02:47:32 +00:00
|
|
|
freestyle_scene->r.cfra = old_scene->r.cfra;
|
2012-12-18 00:51:25 +00:00
|
|
|
freestyle_scene->r.mode = old_scene->r.mode & ~(R_EDGE_FRS | R_BORDER);
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
freestyle_scene->r.xsch = re->rectx; // old_scene->r.xsch
|
|
|
|
|
freestyle_scene->r.ysch = re->recty; // old_scene->r.ysch
|
|
|
|
|
freestyle_scene->r.xasp = 1.0f; // old_scene->r.xasp;
|
|
|
|
|
freestyle_scene->r.yasp = 1.0f; // old_scene->r.yasp;
|
2012-12-18 00:51:25 +00:00
|
|
|
freestyle_scene->r.size = 100; // old_scene->r.size
|
2012-01-21 21:58:47 +00:00
|
|
|
freestyle_scene->r.color_mgt_flag = 0; // old_scene->r.color_mgt_flag;
|
2018-11-04 20:34:02 +01:00
|
|
|
freestyle_scene->r.scemode = (old_scene->r.scemode &
|
|
|
|
|
~(R_SINGLE_LAYER | R_NO_FRAME_UPDATE | R_MULTIVIEW)) &
|
Cycles: merge of cycles-x branch, a major update to the renderer
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
2021-09-20 17:59:20 +02:00
|
|
|
(re->r.scemode);
|
2012-12-18 00:51:25 +00:00
|
|
|
freestyle_scene->r.flag = old_scene->r.flag;
|
|
|
|
|
freestyle_scene->r.threads = old_scene->r.threads;
|
|
|
|
|
freestyle_scene->r.border.xmin = old_scene->r.border.xmin;
|
|
|
|
|
freestyle_scene->r.border.ymin = old_scene->r.border.ymin;
|
|
|
|
|
freestyle_scene->r.border.xmax = old_scene->r.border.xmax;
|
|
|
|
|
freestyle_scene->r.border.ymax = old_scene->r.border.ymax;
|
2023-06-19 20:06:55 +10:00
|
|
|
STRNCPY(freestyle_scene->r.pic, old_scene->r.pic);
|
2012-12-18 00:51:25 +00:00
|
|
|
freestyle_scene->r.dither_intensity = old_scene->r.dither_intensity;
|
2018-04-17 13:35:05 +02:00
|
|
|
STRNCPY(freestyle_scene->r.engine, old_scene->r.engine);
|
2018-02-06 08:53:59 +09:00
|
|
|
if (G.debug & G_DEBUG_FREESTYLE) {
|
2018-04-17 13:35:05 +02:00
|
|
|
cout << "Stroke rendering engine : " << freestyle_scene->r.engine << endl;
|
2018-02-06 08:53:59 +09:00
|
|
|
}
|
2017-10-16 17:15:03 -02:00
|
|
|
freestyle_scene->r.im_format.planes = R_IMF_PLANES_RGBA;
|
2011-11-26 13:11:55 +00:00
|
|
|
freestyle_scene->r.im_format.imtype = R_IMF_IMTYPE_PNG;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-02-05 16:16:09 +01:00
|
|
|
// Copy ID properties, including Cycles render properties
|
|
|
|
|
if (old_scene->id.properties) {
|
|
|
|
|
freestyle_scene->id.properties = IDP_CopyProperty_ex(old_scene->id.properties, 0);
|
|
|
|
|
}
|
2019-06-04 20:07:15 +02:00
|
|
|
// Copy eevee render settings.
|
2020-01-28 18:19:44 +01:00
|
|
|
BKE_scene_copy_data_eevee(freestyle_scene, old_scene);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-04 17:06:50 +01:00
|
|
|
/* Render with transparent background. */
|
|
|
|
|
freestyle_scene->r.alphamode = R_ALPHAPREMUL;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-01-18 02:13:36 +00:00
|
|
|
if (G.debug & G_DEBUG_FREESTYLE) {
|
2014-07-04 15:18:06 +09:00
|
|
|
printf("%s: %d thread(s)\n", __func__, BKE_render_num_threads(&freestyle_scene->r));
|
2013-01-18 02:13:36 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-11-03 14:36:49 +01:00
|
|
|
BKE_scene_set_background(freestyle_bmain, freestyle_scene);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-11-03 14:36:49 +01:00
|
|
|
// Scene layer.
|
2017-11-22 10:52:39 -02:00
|
|
|
ViewLayer *view_layer = (ViewLayer *)freestyle_scene->view_layers.first;
|
2021-07-29 16:34:54 +02:00
|
|
|
view_layer->layflag = SCE_LAY_SOLID;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
2008-12-01 21:30:44 +00:00
|
|
|
// Camera
|
2022-09-14 21:30:20 +02:00
|
|
|
Object *object_camera = BKE_object_add(
|
|
|
|
|
freestyle_bmain, freestyle_scene, view_layer, OB_CAMERA, nullptr);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-03-07 23:17:23 +00:00
|
|
|
Camera *camera = (Camera *)object_camera->data;
|
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
2008-12-01 21:30:44 +00:00
|
|
|
camera->type = CAM_ORTHO;
|
2011-11-06 12:23:44 +00:00
|
|
|
camera->ortho_scale = max(re->rectx, re->recty);
|
2019-02-16 12:21:44 +11:00
|
|
|
camera->clip_start = 0.1f;
|
|
|
|
|
camera->clip_end = 100.0f;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-12-18 00:51:25 +00:00
|
|
|
_z_delta = 0.00001f;
|
2019-02-16 12:21:44 +11:00
|
|
|
_z = camera->clip_start + _z_delta;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-11-06 12:23:44 +00:00
|
|
|
object_camera->loc[0] = re->disprect.xmin + 0.5f * re->rectx;
|
|
|
|
|
object_camera->loc[1] = re->disprect.ymin + 0.5f * re->recty;
|
2012-12-18 00:51:25 +00:00
|
|
|
object_camera->loc[2] = 1.0f;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-09-28 03:56:31 +00:00
|
|
|
freestyle_scene->camera = object_camera;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-02-14 19:19:44 +00:00
|
|
|
// Reset serial mesh ID (used for BlenderStrokeRenderer::NewMesh())
|
|
|
|
|
_mesh_id = 0xffffffff;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-19 23:42:15 +09:00
|
|
|
// Create a bNodeTree-to-Material hash table
|
Remove Blender Internal and legacy viewport from Blender 2.8.
Brecht authored this commit, but he gave me the honours to actually
do it. Here it goes; Blender Internal. Bye bye, you did great!
* Point density, voxel data, ocean, environment map textures were removed,
as these only worked within BI rendering. Note that the ocean modifier
and the Cycles point density shader node continue to work.
* Dynamic paint using material shading was removed, as this only worked
with BI. If we ever wanted to support this again probably it should go
through the baking API.
* GPU shader export through the Python API was removed. This only worked
for the old BI GLSL shaders, which no longer exists. Doing something
similar for Eevee would be significantly more complicated because it
uses a lot of multiplass rendering and logic outside the shader, it's
probably impractical.
* Collada material import / export code is mostly gone, as it only worked
for BI materials. We need to add Cycles / Eevee material support at some
point.
* The mesh noise operator was removed since it only worked with BI
material texture slots. A displacement modifier can be used instead.
* The delete texture paint slot operator was removed since it only worked
for BI material texture slots. Could be added back with node support.
* Not all legacy viewport features are supported in the new viewport, but
their code was removed. If we need to bring anything back we can look at
older git revisions.
* There is some legacy viewport code that I could not remove yet, and some
that I probably missed.
* Shader node execution code was left mostly intact, even though it is not
used anywhere now. We may eventually use this to replace the texture
nodes with Cycles / Eevee shader nodes.
* The Cycles Bake panel now includes settings for baking multires normal
and displacement maps. The underlying code needs to be merged properly,
and we plan to add back support for multires AO baking and add support
to Cycles baking for features like vertex color, displacement, and other
missing baking features.
* This commit removes DNA and the Python API for BI material, lamp, world
and scene settings. This breaks a lot of addons.
* There is more DNA that can be removed or renamed, where Cycles or Eevee
are reusing some old BI properties but the names are not really correct
anymore.
* Texture slots for materials, lamps and world were removed. They remain
for brushes, particles and freestyle linestyles.
* 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and
other renderers use this to find all panels to show, minus a few panels
that they have their own replacement for.
2018-04-19 17:34:44 +02:00
|
|
|
_nodetree_hash = BLI_ghash_ptr_new("BlenderStrokeRenderer::_nodetree_hash");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-06 09:17:53 +02:00
|
|
|
// Depsgraph
|
2019-09-09 14:49:05 +02:00
|
|
|
freestyle_depsgraph = DEG_graph_new(
|
|
|
|
|
freestyle_bmain, freestyle_scene, view_layer, DAG_EVAL_RENDER);
|
2018-04-06 09:17:53 +02:00
|
|
|
DEG_graph_id_tag_update(freestyle_bmain, freestyle_depsgraph, &freestyle_scene->id, 0);
|
|
|
|
|
DEG_graph_id_tag_update(freestyle_bmain, freestyle_depsgraph, &object_camera->id, 0);
|
2017-11-03 14:36:49 +01:00
|
|
|
DEG_graph_tag_relations_update(freestyle_depsgraph);
|
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
2008-12-01 21:30:44 +00:00
|
|
|
}
|
|
|
|
|
|
2012-12-18 00:51:25 +00:00
|
|
|
BlenderStrokeRenderer::~BlenderStrokeRenderer()
|
|
|
|
|
{
|
2020-11-06 17:49:09 +01:00
|
|
|
BLI_ghash_free(_nodetree_hash, nullptr, nullptr);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-11-03 14:36:49 +01:00
|
|
|
DEG_graph_free(freestyle_depsgraph);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
FreeStrokeGroups();
|
2020-03-26 01:14:08 +01:00
|
|
|
|
|
|
|
|
/* detach the window manager from freestyle bmain (see comments
|
|
|
|
|
* in add_freestyle() for more detail)
|
|
|
|
|
*/
|
|
|
|
|
BLI_listbase_clear(&freestyle_bmain->wm);
|
|
|
|
|
|
|
|
|
|
BKE_main_free(freestyle_bmain);
|
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
2008-12-01 21:30:44 +00:00
|
|
|
}
|
|
|
|
|
|
2020-11-06 13:18:48 +01:00
|
|
|
float BlenderStrokeRenderer::get_stroke_vertex_z() const
|
2012-12-18 00:51:25 +00:00
|
|
|
{
|
|
|
|
|
float z = _z;
|
|
|
|
|
BlenderStrokeRenderer *self = const_cast<BlenderStrokeRenderer *>(this);
|
2019-05-31 22:51:19 +10:00
|
|
|
if (!(_z < _z_delta * 100000.0f)) {
|
2012-12-18 00:51:25 +00:00
|
|
|
self->_z_delta *= 10.0f;
|
2019-05-31 22:51:19 +10:00
|
|
|
}
|
2012-12-18 00:51:25 +00:00
|
|
|
self->_z += _z_delta;
|
|
|
|
|
return -z;
|
2010-02-16 02:10:27 +00:00
|
|
|
}
|
|
|
|
|
|
2022-09-25 17:04:52 +10:00
|
|
|
uint BlenderStrokeRenderer::get_stroke_mesh_id() const
|
2013-02-14 19:19:44 +00:00
|
|
|
{
|
2022-09-26 10:04:44 +10:00
|
|
|
uint mesh_id = _mesh_id;
|
2013-02-14 19:19:44 +00:00
|
|
|
BlenderStrokeRenderer *self = const_cast<BlenderStrokeRenderer *>(this);
|
|
|
|
|
self->_mesh_id--;
|
|
|
|
|
return mesh_id;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-25 11:42:28 +11:00
|
|
|
Material *BlenderStrokeRenderer::GetStrokeShader(Main *bmain,
|
|
|
|
|
bNodeTree *iNodeTree,
|
|
|
|
|
bool do_id_user)
|
2012-12-18 00:51:25 +00:00
|
|
|
{
|
2014-07-16 00:21:27 +09:00
|
|
|
Material *ma = BKE_material_add(bmain, "stroke_shader");
|
|
|
|
|
bNodeTree *ntree;
|
2020-11-06 17:49:09 +01:00
|
|
|
bNode *output_linestyle = nullptr;
|
2014-07-16 00:21:27 +09:00
|
|
|
bNodeSocket *fromsock, *tosock;
|
|
|
|
|
PointerRNA fromptr, toptr;
|
2014-07-21 15:08:07 +09:00
|
|
|
NodeShaderAttribute *storage;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-04-04 15:43:45 +02:00
|
|
|
id_us_min(&ma->id);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-19 18:52:32 +09:00
|
|
|
if (iNodeTree) {
|
2014-07-16 00:21:27 +09:00
|
|
|
// make a copy of linestyle->nodetree
|
2023-05-15 15:14:22 +02:00
|
|
|
ntree = blender::bke::ntreeCopyTree_ex(iNodeTree, bmain, do_id_user);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-16 00:21:27 +09:00
|
|
|
// find the active Output Line Style node
|
2023-08-04 08:51:13 +10:00
|
|
|
LISTBASE_FOREACH (bNode *, node, &ntree->nodes) {
|
2014-07-16 00:21:27 +09:00
|
|
|
if (node->type == SH_NODE_OUTPUT_LINESTYLE && (node->flag & NODE_DO_OUTPUT)) {
|
|
|
|
|
output_linestyle = node;
|
2014-05-03 18:51:53 +09:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2022-09-05 15:46:00 +02:00
|
|
|
ma->nodetree = ntree;
|
2014-07-16 00:21:27 +09:00
|
|
|
}
|
|
|
|
|
else {
|
2023-05-15 15:14:22 +02:00
|
|
|
ntree = blender::bke::ntreeAddTreeEmbedded(
|
|
|
|
|
nullptr, &ma->id, "stroke_shader", "ShaderNodeTree");
|
2014-07-16 00:21:27 +09:00
|
|
|
}
|
2022-09-05 15:46:00 +02:00
|
|
|
ma->use_nodes = true;
|
2019-05-21 17:42:24 +02:00
|
|
|
ma->blend_method = MA_BM_HASHED;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-11-06 17:49:09 +01:00
|
|
|
bNode *input_attr_color = nodeAddStaticNode(nullptr, ntree, SH_NODE_ATTRIBUTE);
|
2014-07-21 15:08:07 +09:00
|
|
|
input_attr_color->locx = 0.0f;
|
|
|
|
|
input_attr_color->locy = -200.0f;
|
|
|
|
|
storage = (NodeShaderAttribute *)input_attr_color->storage;
|
2023-05-09 12:50:37 +10:00
|
|
|
STRNCPY(storage->name, "Color");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-08-30 11:05:46 +01:00
|
|
|
bNode *mix_rgb_color = nodeAddStaticNode(nullptr, ntree, SH_NODE_MIX_RGB_LEGACY);
|
2014-07-21 15:08:07 +09:00
|
|
|
mix_rgb_color->custom1 = MA_RAMP_BLEND; // Mix
|
|
|
|
|
mix_rgb_color->locx = 200.0f;
|
|
|
|
|
mix_rgb_color->locy = -200.0f;
|
|
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&mix_rgb_color->inputs, 0); // Fac
|
2023-09-06 00:48:50 +02:00
|
|
|
toptr = RNA_pointer_create((ID *)ntree, &RNA_NodeSocket, tosock);
|
2014-07-21 15:08:07 +09:00
|
|
|
RNA_float_set(&toptr, "default_value", 0.0f);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-11-06 17:49:09 +01:00
|
|
|
bNode *input_attr_alpha = nodeAddStaticNode(nullptr, ntree, SH_NODE_ATTRIBUTE);
|
2014-07-21 15:08:07 +09:00
|
|
|
input_attr_alpha->locx = 400.0f;
|
|
|
|
|
input_attr_alpha->locy = 300.0f;
|
|
|
|
|
storage = (NodeShaderAttribute *)input_attr_alpha->storage;
|
2023-05-09 12:50:37 +10:00
|
|
|
STRNCPY(storage->name, "Alpha");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-08-30 11:05:46 +01:00
|
|
|
bNode *mix_rgb_alpha = nodeAddStaticNode(nullptr, ntree, SH_NODE_MIX_RGB_LEGACY);
|
2014-07-21 15:08:07 +09:00
|
|
|
mix_rgb_alpha->custom1 = MA_RAMP_BLEND; // Mix
|
|
|
|
|
mix_rgb_alpha->locx = 600.0f;
|
|
|
|
|
mix_rgb_alpha->locy = 300.0f;
|
2014-07-21 18:47:19 +09:00
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&mix_rgb_alpha->inputs, 0); // Fac
|
2023-09-06 00:48:50 +02:00
|
|
|
toptr = RNA_pointer_create((ID *)ntree, &RNA_NodeSocket, tosock);
|
2014-07-16 15:27:40 +09:00
|
|
|
RNA_float_set(&toptr, "default_value", 0.0f);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-11-06 17:49:09 +01:00
|
|
|
bNode *shader_emission = nodeAddStaticNode(nullptr, ntree, SH_NODE_EMISSION);
|
2014-07-16 00:21:27 +09:00
|
|
|
shader_emission->locx = 400.0f;
|
|
|
|
|
shader_emission->locy = -200.0f;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-11-06 17:49:09 +01:00
|
|
|
bNode *input_light_path = nodeAddStaticNode(nullptr, ntree, SH_NODE_LIGHT_PATH);
|
2014-07-16 00:21:27 +09:00
|
|
|
input_light_path->locx = 400.0f;
|
|
|
|
|
input_light_path->locy = 100.0f;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-11-06 17:49:09 +01:00
|
|
|
bNode *mix_shader_color = nodeAddStaticNode(nullptr, ntree, SH_NODE_MIX_SHADER);
|
2014-07-21 15:08:07 +09:00
|
|
|
mix_shader_color->locx = 600.0f;
|
|
|
|
|
mix_shader_color->locy = -100.0f;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-11-06 17:49:09 +01:00
|
|
|
bNode *shader_transparent = nodeAddStaticNode(nullptr, ntree, SH_NODE_BSDF_TRANSPARENT);
|
2014-07-21 15:08:07 +09:00
|
|
|
shader_transparent->locx = 600.0f;
|
|
|
|
|
shader_transparent->locy = 100.0f;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-11-06 17:49:09 +01:00
|
|
|
bNode *mix_shader_alpha = nodeAddStaticNode(nullptr, ntree, SH_NODE_MIX_SHADER);
|
2014-07-21 15:08:07 +09:00
|
|
|
mix_shader_alpha->locx = 800.0f;
|
|
|
|
|
mix_shader_alpha->locy = 100.0f;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-11-06 17:49:09 +01:00
|
|
|
bNode *output_material = nodeAddStaticNode(nullptr, ntree, SH_NODE_OUTPUT_MATERIAL);
|
2014-07-21 15:08:07 +09:00
|
|
|
output_material->locx = 1000.0f;
|
2014-07-16 00:21:27 +09:00
|
|
|
output_material->locy = 100.0f;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-21 15:08:07 +09:00
|
|
|
fromsock = (bNodeSocket *)BLI_findlink(&input_attr_color->outputs, 0); // Color
|
|
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&mix_rgb_color->inputs, 1); // Color1
|
|
|
|
|
nodeAddLink(ntree, input_attr_color, fromsock, mix_rgb_color, tosock);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-21 15:08:07 +09:00
|
|
|
fromsock = (bNodeSocket *)BLI_findlink(&mix_rgb_color->outputs, 0); // Color
|
2014-07-16 00:21:27 +09:00
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&shader_emission->inputs, 0); // Color
|
2014-07-21 15:08:07 +09:00
|
|
|
nodeAddLink(ntree, mix_rgb_color, fromsock, shader_emission, tosock);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-16 00:21:27 +09:00
|
|
|
fromsock = (bNodeSocket *)BLI_findlink(&shader_emission->outputs, 0); // Emission
|
2014-07-21 15:08:07 +09:00
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&mix_shader_color->inputs, 2); // Shader (second)
|
|
|
|
|
nodeAddLink(ntree, shader_emission, fromsock, mix_shader_color, tosock);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-16 00:21:27 +09:00
|
|
|
fromsock = (bNodeSocket *)BLI_findlink(&input_light_path->outputs, 0); // In Camera Ray
|
2014-07-21 15:08:07 +09:00
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&mix_shader_color->inputs, 0); // Fac
|
|
|
|
|
nodeAddLink(ntree, input_light_path, fromsock, mix_shader_color, tosock);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-21 15:08:07 +09:00
|
|
|
fromsock = (bNodeSocket *)BLI_findlink(&mix_rgb_alpha->outputs, 0); // Color
|
|
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&mix_shader_alpha->inputs, 0); // Fac
|
|
|
|
|
nodeAddLink(ntree, mix_rgb_alpha, fromsock, mix_shader_alpha, tosock);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-21 15:08:07 +09:00
|
|
|
fromsock = (bNodeSocket *)BLI_findlink(&input_attr_alpha->outputs, 0); // Color
|
|
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&mix_rgb_alpha->inputs, 1); // Color1
|
|
|
|
|
nodeAddLink(ntree, input_attr_alpha, fromsock, mix_rgb_alpha, tosock);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-21 15:08:07 +09:00
|
|
|
fromsock = (bNodeSocket *)BLI_findlink(&shader_transparent->outputs, 0); // BSDF
|
|
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&mix_shader_alpha->inputs, 1); // Shader (first)
|
|
|
|
|
nodeAddLink(ntree, shader_transparent, fromsock, mix_shader_alpha, tosock);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-21 15:08:07 +09:00
|
|
|
fromsock = (bNodeSocket *)BLI_findlink(&mix_shader_color->outputs, 0); // Shader
|
|
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&mix_shader_alpha->inputs, 2); // Shader (second)
|
|
|
|
|
nodeAddLink(ntree, mix_shader_color, fromsock, mix_shader_alpha, tosock);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-21 15:08:07 +09:00
|
|
|
fromsock = (bNodeSocket *)BLI_findlink(&mix_shader_alpha->outputs, 0); // Shader
|
2014-07-16 00:21:27 +09:00
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&output_material->inputs, 0); // Surface
|
2014-07-21 15:08:07 +09:00
|
|
|
nodeAddLink(ntree, mix_shader_alpha, fromsock, output_material, tosock);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-16 00:21:27 +09:00
|
|
|
if (output_linestyle) {
|
|
|
|
|
bNodeSocket *outsock;
|
|
|
|
|
bNodeLink *link;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-21 15:08:07 +09:00
|
|
|
mix_rgb_color->custom1 = output_linestyle->custom1; // blend_type
|
|
|
|
|
mix_rgb_color->custom2 = output_linestyle->custom2; // use_clamp
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-16 00:21:27 +09:00
|
|
|
outsock = (bNodeSocket *)BLI_findlink(&output_linestyle->inputs, 0); // Color
|
2014-07-21 15:08:07 +09:00
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&mix_rgb_color->inputs, 2); // Color2
|
2014-07-16 00:21:27 +09:00
|
|
|
link = (bNodeLink *)BLI_findptr(&ntree->links, outsock, offsetof(bNodeLink, tosock));
|
|
|
|
|
if (link) {
|
2014-07-21 15:08:07 +09:00
|
|
|
nodeAddLink(ntree, link->fromnode, link->fromsock, mix_rgb_color, tosock);
|
2014-07-16 00:21:27 +09:00
|
|
|
}
|
2014-07-16 15:27:40 +09:00
|
|
|
else {
|
|
|
|
|
float color[4];
|
2023-09-06 00:48:50 +02:00
|
|
|
fromptr = RNA_pointer_create((ID *)ntree, &RNA_NodeSocket, outsock);
|
|
|
|
|
toptr = RNA_pointer_create((ID *)ntree, &RNA_NodeSocket, tosock);
|
2014-07-16 15:27:40 +09:00
|
|
|
RNA_float_get_array(&fromptr, "default_value", color);
|
|
|
|
|
RNA_float_set_array(&toptr, "default_value", color);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-16 00:21:27 +09:00
|
|
|
outsock = (bNodeSocket *)BLI_findlink(&output_linestyle->inputs, 1); // Color Fac
|
2014-07-21 15:08:07 +09:00
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&mix_rgb_color->inputs, 0); // Fac
|
2014-07-16 00:21:27 +09:00
|
|
|
link = (bNodeLink *)BLI_findptr(&ntree->links, outsock, offsetof(bNodeLink, tosock));
|
|
|
|
|
if (link) {
|
2014-07-21 15:08:07 +09:00
|
|
|
nodeAddLink(ntree, link->fromnode, link->fromsock, mix_rgb_color, tosock);
|
2014-05-03 18:51:53 +09:00
|
|
|
}
|
2014-07-16 00:21:27 +09:00
|
|
|
else {
|
2023-09-06 00:48:50 +02:00
|
|
|
fromptr = RNA_pointer_create((ID *)ntree, &RNA_NodeSocket, outsock);
|
|
|
|
|
toptr = RNA_pointer_create((ID *)ntree, &RNA_NodeSocket, tosock);
|
2014-07-16 00:21:27 +09:00
|
|
|
RNA_float_set(&toptr, "default_value", RNA_float_get(&fromptr, "default_value"));
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-16 00:21:27 +09:00
|
|
|
outsock = (bNodeSocket *)BLI_findlink(&output_linestyle->inputs, 2); // Alpha
|
2014-07-21 15:08:07 +09:00
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&mix_rgb_alpha->inputs, 2); // Color2
|
|
|
|
|
link = (bNodeLink *)BLI_findptr(&ntree->links, outsock, offsetof(bNodeLink, tosock));
|
|
|
|
|
if (link) {
|
|
|
|
|
nodeAddLink(ntree, link->fromnode, link->fromsock, mix_rgb_alpha, tosock);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
float color[4];
|
2023-09-06 00:48:50 +02:00
|
|
|
fromptr = RNA_pointer_create((ID *)ntree, &RNA_NodeSocket, outsock);
|
|
|
|
|
toptr = RNA_pointer_create((ID *)ntree, &RNA_NodeSocket, tosock);
|
2014-07-21 15:08:07 +09:00
|
|
|
color[0] = color[1] = color[2] = RNA_float_get(&fromptr, "default_value");
|
|
|
|
|
color[3] = 1.0f;
|
|
|
|
|
RNA_float_set_array(&toptr, "default_value", color);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-16 00:21:27 +09:00
|
|
|
outsock = (bNodeSocket *)BLI_findlink(&output_linestyle->inputs, 3); // Alpha Fac
|
2014-07-21 15:08:07 +09:00
|
|
|
tosock = (bNodeSocket *)BLI_findlink(&mix_rgb_alpha->inputs, 0); // Fac
|
|
|
|
|
link = (bNodeLink *)BLI_findptr(&ntree->links, outsock, offsetof(bNodeLink, tosock));
|
|
|
|
|
if (link) {
|
|
|
|
|
nodeAddLink(ntree, link->fromnode, link->fromsock, mix_rgb_alpha, tosock);
|
|
|
|
|
}
|
|
|
|
|
else {
|
2023-09-06 00:48:50 +02:00
|
|
|
fromptr = RNA_pointer_create((ID *)ntree, &RNA_NodeSocket, outsock);
|
|
|
|
|
toptr = RNA_pointer_create((ID *)ntree, &RNA_NodeSocket, tosock);
|
2014-07-21 15:08:07 +09:00
|
|
|
RNA_float_set(&toptr, "default_value", RNA_float_get(&fromptr, "default_value"));
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-08-04 08:51:13 +10:00
|
|
|
LISTBASE_FOREACH (bNode *, node, &ntree->nodes) {
|
2014-07-20 16:21:05 +09:00
|
|
|
if (node->type == SH_NODE_UVALONGSTROKE) {
|
|
|
|
|
// UV output of the UV Along Stroke node
|
|
|
|
|
bNodeSocket *sock = (bNodeSocket *)BLI_findlink(&node->outputs, 0);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-20 16:21:05 +09:00
|
|
|
// add new UV Map node
|
2020-11-06 17:49:09 +01:00
|
|
|
bNode *input_uvmap = nodeAddStaticNode(nullptr, ntree, SH_NODE_UVMAP);
|
2014-07-19 15:38:56 +09:00
|
|
|
input_uvmap->locx = node->locx - 200.0f;
|
|
|
|
|
input_uvmap->locy = node->locy;
|
|
|
|
|
NodeShaderUVMap *storage = (NodeShaderUVMap *)input_uvmap->storage;
|
2014-07-20 16:21:05 +09:00
|
|
|
if (node->custom1 & 1) { // use_tips
|
2023-05-09 12:50:37 +10:00
|
|
|
STRNCPY(storage->uv_map, uvNames[1]);
|
2014-07-20 16:21:05 +09:00
|
|
|
}
|
|
|
|
|
else {
|
2023-05-09 12:50:37 +10:00
|
|
|
STRNCPY(storage->uv_map, uvNames[0]);
|
2014-07-20 16:21:05 +09:00
|
|
|
}
|
2014-07-19 15:38:56 +09:00
|
|
|
fromsock = (bNodeSocket *)BLI_findlink(&input_uvmap->outputs, 0); // UV
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-20 16:21:05 +09:00
|
|
|
// replace links from the UV Along Stroke node by links from the UV Map node
|
2023-08-04 08:51:13 +10:00
|
|
|
LISTBASE_FOREACH (bNodeLink *, link, &ntree->links) {
|
2014-07-20 16:21:05 +09:00
|
|
|
if (link->fromnode == node && link->fromsock == sock) {
|
|
|
|
|
nodeAddLink(ntree, input_uvmap, fromsock, link->tonode, link->tosock);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
nodeRemSocketLinks(ntree, sock);
|
2014-07-19 15:38:56 +09:00
|
|
|
}
|
|
|
|
|
}
|
2014-05-03 18:51:53 +09:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-21 15:08:07 +09:00
|
|
|
nodeSetActive(ntree, output_material);
|
2021-12-27 18:18:37 +01:00
|
|
|
BKE_ntree_update_main_tree(bmain, ntree, nullptr);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-16 00:21:27 +09:00
|
|
|
return ma;
|
|
|
|
|
}
|
2014-05-03 18:51:53 +09:00
|
|
|
|
2014-07-16 00:21:27 +09:00
|
|
|
void BlenderStrokeRenderer::RenderStrokeRep(StrokeRep *iStrokeRep) const
|
2014-08-08 22:29:02 +09:00
|
|
|
{
|
|
|
|
|
RenderStrokeRepBasic(iStrokeRep);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void BlenderStrokeRenderer::RenderStrokeRepBasic(StrokeRep *iStrokeRep) const
|
2014-07-16 00:21:27 +09:00
|
|
|
{
|
Remove Blender Internal and legacy viewport from Blender 2.8.
Brecht authored this commit, but he gave me the honours to actually
do it. Here it goes; Blender Internal. Bye bye, you did great!
* Point density, voxel data, ocean, environment map textures were removed,
as these only worked within BI rendering. Note that the ocean modifier
and the Cycles point density shader node continue to work.
* Dynamic paint using material shading was removed, as this only worked
with BI. If we ever wanted to support this again probably it should go
through the baking API.
* GPU shader export through the Python API was removed. This only worked
for the old BI GLSL shaders, which no longer exists. Doing something
similar for Eevee would be significantly more complicated because it
uses a lot of multiplass rendering and logic outside the shader, it's
probably impractical.
* Collada material import / export code is mostly gone, as it only worked
for BI materials. We need to add Cycles / Eevee material support at some
point.
* The mesh noise operator was removed since it only worked with BI
material texture slots. A displacement modifier can be used instead.
* The delete texture paint slot operator was removed since it only worked
for BI material texture slots. Could be added back with node support.
* Not all legacy viewport features are supported in the new viewport, but
their code was removed. If we need to bring anything back we can look at
older git revisions.
* There is some legacy viewport code that I could not remove yet, and some
that I probably missed.
* Shader node execution code was left mostly intact, even though it is not
used anywhere now. We may eventually use this to replace the texture
nodes with Cycles / Eevee shader nodes.
* The Cycles Bake panel now includes settings for baking multires normal
and displacement maps. The underlying code needs to be merged properly,
and we plan to add back support for multires AO baking and add support
to Cycles baking for features like vertex color, displacement, and other
missing baking features.
* This commit removes DNA and the Python API for BI material, lamp, world
and scene settings. This breaks a lot of addons.
* There is more DNA that can be removed or renamed, where Cycles or Eevee
are reusing some old BI properties but the names are not really correct
anymore.
* Texture slots for materials, lamps and world were removed. They remain
for brushes, particles and freestyle linestyles.
* 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and
other renderers use this to find all panels to show, minus a few panels
that they have their own replacement for.
2018-04-19 17:34:44 +02:00
|
|
|
bNodeTree *nt = iStrokeRep->getNodeTree();
|
|
|
|
|
Material *ma = (Material *)BLI_ghash_lookup(_nodetree_hash, nt);
|
|
|
|
|
if (!ma) {
|
|
|
|
|
ma = BlenderStrokeRenderer::GetStrokeShader(freestyle_bmain, nt, false);
|
|
|
|
|
BLI_ghash_insert(_nodetree_hash, nt, ma);
|
2014-07-16 00:21:27 +09:00
|
|
|
}
|
Remove Blender Internal and legacy viewport from Blender 2.8.
Brecht authored this commit, but he gave me the honours to actually
do it. Here it goes; Blender Internal. Bye bye, you did great!
* Point density, voxel data, ocean, environment map textures were removed,
as these only worked within BI rendering. Note that the ocean modifier
and the Cycles point density shader node continue to work.
* Dynamic paint using material shading was removed, as this only worked
with BI. If we ever wanted to support this again probably it should go
through the baking API.
* GPU shader export through the Python API was removed. This only worked
for the old BI GLSL shaders, which no longer exists. Doing something
similar for Eevee would be significantly more complicated because it
uses a lot of multiplass rendering and logic outside the shader, it's
probably impractical.
* Collada material import / export code is mostly gone, as it only worked
for BI materials. We need to add Cycles / Eevee material support at some
point.
* The mesh noise operator was removed since it only worked with BI
material texture slots. A displacement modifier can be used instead.
* The delete texture paint slot operator was removed since it only worked
for BI material texture slots. Could be added back with node support.
* Not all legacy viewport features are supported in the new viewport, but
their code was removed. If we need to bring anything back we can look at
older git revisions.
* There is some legacy viewport code that I could not remove yet, and some
that I probably missed.
* Shader node execution code was left mostly intact, even though it is not
used anywhere now. We may eventually use this to replace the texture
nodes with Cycles / Eevee shader nodes.
* The Cycles Bake panel now includes settings for baking multires normal
and displacement maps. The underlying code needs to be merged properly,
and we plan to add back support for multires AO baking and add support
to Cycles baking for features like vertex color, displacement, and other
missing baking features.
* This commit removes DNA and the Python API for BI material, lamp, world
and scene settings. This breaks a lot of addons.
* There is more DNA that can be removed or renamed, where Cycles or Eevee
are reusing some old BI properties but the names are not really correct
anymore.
* Texture slots for materials, lamps and world were removed. They remain
for brushes, particles and freestyle linestyles.
* 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and
other renderers use this to find all panels to show, minus a few panels
that they have their own replacement for.
2018-04-19 17:34:44 +02:00
|
|
|
iStrokeRep->setMaterial(ma);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
const vector<Strip *> &strips = iStrokeRep->getStrips();
|
|
|
|
|
const bool hasTex = iStrokeRep->hasTex();
|
2023-07-24 22:06:55 +02:00
|
|
|
int totvert = 0, totedge = 0, faces_num = 0, totloop = 0;
|
2014-08-08 22:29:02 +09:00
|
|
|
int visible_faces, visible_segments;
|
|
|
|
|
for (vector<Strip *>::const_iterator s = strips.begin(), send = strips.end(); s != send; ++s) {
|
|
|
|
|
Strip::vertex_container &strip_vertices = (*s)->vertices();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
// count visible faces and strip segments
|
|
|
|
|
test_strip_visibility(strip_vertices, &visible_faces, &visible_segments);
|
2019-05-31 22:51:19 +10:00
|
|
|
if (visible_faces == 0) {
|
2014-08-08 22:29:02 +09:00
|
|
|
continue;
|
2019-05-31 22:51:19 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
totvert += visible_faces + visible_segments * 2;
|
|
|
|
|
totedge += visible_faces * 2 + visible_segments;
|
2023-07-24 22:06:55 +02:00
|
|
|
faces_num += visible_faces;
|
2014-08-08 22:29:02 +09:00
|
|
|
totloop += visible_faces * 3;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
BlenderStrokeRenderer *self = const_cast<BlenderStrokeRenderer *>(this); // FIXME
|
|
|
|
|
vector<StrokeGroup *> *groups = hasTex ? &self->texturedStrokeGroups : &self->strokeGroups;
|
|
|
|
|
StrokeGroup *group;
|
|
|
|
|
if (groups->empty() || !(groups->back()->totvert + totvert < MESH_MAX_VERTS &&
|
2020-05-12 18:52:07 +02:00
|
|
|
groups->back()->materials.size() + 1 < MAXMAT))
|
|
|
|
|
{
|
2014-08-08 22:29:02 +09:00
|
|
|
group = new StrokeGroup;
|
|
|
|
|
groups->push_back(group);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
group = groups->back();
|
|
|
|
|
}
|
|
|
|
|
group->strokes.push_back(iStrokeRep);
|
|
|
|
|
group->totvert += totvert;
|
|
|
|
|
group->totedge += totedge;
|
2023-07-24 22:06:55 +02:00
|
|
|
group->faces_num += faces_num;
|
2014-08-08 22:29:02 +09:00
|
|
|
group->totloop += totloop;
|
2020-05-12 18:52:07 +02:00
|
|
|
|
|
|
|
|
if (!group->materials.contains(ma)) {
|
|
|
|
|
group->materials.add_new(ma, group->materials.size());
|
|
|
|
|
}
|
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
2008-12-01 21:30:44 +00:00
|
|
|
}
|
|
|
|
|
|
2014-05-09 11:58:25 +09:00
|
|
|
// Check if the triangle is visible (i.e., within the render image boundary)
|
|
|
|
|
bool BlenderStrokeRenderer::test_triangle_visibility(StrokeVertexRep *svRep[3]) const
|
2012-12-18 00:51:25 +00:00
|
|
|
{
|
2014-05-09 11:58:25 +09:00
|
|
|
int xl, xu, yl, yu;
|
|
|
|
|
Vec2r p;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-05-09 11:58:25 +09:00
|
|
|
xl = xu = yl = yu = 0;
|
|
|
|
|
for (int i = 0; i < 3; i++) {
|
|
|
|
|
p = svRep[i]->point2d();
|
2019-05-31 22:51:19 +10:00
|
|
|
if (p[0] < 0.0) {
|
2014-05-09 11:58:25 +09:00
|
|
|
xl++;
|
2019-05-31 22:51:19 +10:00
|
|
|
}
|
|
|
|
|
else if (p[0] > _width) {
|
2014-05-09 11:58:25 +09:00
|
|
|
xu++;
|
2019-05-31 22:51:19 +10:00
|
|
|
}
|
|
|
|
|
if (p[1] < 0.0) {
|
2014-05-09 11:58:25 +09:00
|
|
|
yl++;
|
2019-05-31 22:51:19 +10:00
|
|
|
}
|
|
|
|
|
else if (p[1] > _height) {
|
2014-05-09 11:58:25 +09:00
|
|
|
yu++;
|
2019-05-31 22:51:19 +10:00
|
|
|
}
|
2014-05-09 11:58:25 +09:00
|
|
|
}
|
|
|
|
|
return !(xl == 3 || xu == 3 || yl == 3 || yu == 3);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Check the visibility of faces and strip segments.
|
|
|
|
|
void BlenderStrokeRenderer::test_strip_visibility(Strip::vertex_container &strip_vertices,
|
|
|
|
|
int *visible_faces,
|
|
|
|
|
int *visible_segments) const
|
|
|
|
|
{
|
|
|
|
|
const int strip_vertex_count = strip_vertices.size();
|
|
|
|
|
Strip::vertex_container::iterator v[3];
|
|
|
|
|
StrokeVertexRep *svRep[3];
|
|
|
|
|
bool visible;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-05-13 09:24:28 +10:00
|
|
|
/* Iterate over all vertices and count visible faces and strip segments
|
|
|
|
|
* (NOTE: a strip segment is a series of visible faces, while two strip
|
|
|
|
|
* segments are separated by one or more invisible faces). */
|
2014-05-09 11:58:25 +09:00
|
|
|
v[0] = strip_vertices.begin();
|
|
|
|
|
v[1] = v[0] + 1;
|
|
|
|
|
v[2] = v[0] + 2;
|
|
|
|
|
*visible_faces = *visible_segments = 0;
|
|
|
|
|
visible = false;
|
|
|
|
|
for (int n = 2; n < strip_vertex_count; n++, v[0]++, v[1]++, v[2]++) {
|
|
|
|
|
svRep[0] = *(v[0]);
|
|
|
|
|
svRep[1] = *(v[1]);
|
|
|
|
|
svRep[2] = *(v[2]);
|
|
|
|
|
if (test_triangle_visibility(svRep)) {
|
|
|
|
|
(*visible_faces)++;
|
2019-05-31 22:51:19 +10:00
|
|
|
if (!visible) {
|
2014-05-09 11:58:25 +09:00
|
|
|
(*visible_segments)++;
|
2019-05-31 22:51:19 +10:00
|
|
|
}
|
2014-05-09 11:58:25 +09:00
|
|
|
visible = true;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
visible = false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2012-12-18 00:51:25 +00:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
// Release allocated memory for stroke groups
|
|
|
|
|
void BlenderStrokeRenderer::FreeStrokeGroups()
|
2014-05-09 11:58:25 +09:00
|
|
|
{
|
2014-08-08 22:29:02 +09:00
|
|
|
vector<StrokeGroup *>::const_iterator it, itend;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
for (it = strokeGroups.begin(), itend = strokeGroups.end(); it != itend; ++it) {
|
|
|
|
|
delete (*it);
|
|
|
|
|
}
|
|
|
|
|
for (it = texturedStrokeGroups.begin(), itend = texturedStrokeGroups.end(); it != itend; ++it) {
|
|
|
|
|
delete (*it);
|
|
|
|
|
}
|
|
|
|
|
}
|
2010-01-26 22:24:53 +00:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
// Build a scene populated by mesh objects representing stylized strokes
|
|
|
|
|
int BlenderStrokeRenderer::GenerateScene()
|
|
|
|
|
{
|
|
|
|
|
vector<StrokeGroup *>::const_iterator it, itend;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
for (it = strokeGroups.begin(), itend = strokeGroups.end(); it != itend; ++it) {
|
|
|
|
|
GenerateStrokeMesh(*it, false);
|
|
|
|
|
}
|
|
|
|
|
for (it = texturedStrokeGroups.begin(), itend = texturedStrokeGroups.end(); it != itend; ++it) {
|
|
|
|
|
GenerateStrokeMesh(*it, true);
|
2014-05-09 11:58:25 +09:00
|
|
|
}
|
2015-01-17 22:33:13 +09:00
|
|
|
return get_stroke_count();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Return the number of strokes
|
|
|
|
|
int BlenderStrokeRenderer::get_stroke_count() const
|
|
|
|
|
{
|
2014-08-08 22:29:02 +09:00
|
|
|
return strokeGroups.size() + texturedStrokeGroups.size();
|
|
|
|
|
}
|
2014-05-09 11:58:25 +09:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
// Build a mesh object representing a group of stylized strokes
|
|
|
|
|
void BlenderStrokeRenderer::GenerateStrokeMesh(StrokeGroup *group, bool hasTex)
|
|
|
|
|
{
|
2012-10-06 14:06:40 +00:00
|
|
|
#if 0
|
2019-04-17 08:24:14 +02:00
|
|
|
Object *object_mesh = BKE_object_add(
|
2020-09-07 14:09:50 +10:00
|
|
|
freestyle_bmain, (ViewLayer *)freestyle_scene->view_layers.first, OB_MESH);
|
2017-06-08 10:14:53 +02:00
|
|
|
DEG_relations_tag_update(freestyle_bmain);
|
2012-10-06 14:06:40 +00:00
|
|
|
#else
|
2014-05-09 11:58:25 +09:00
|
|
|
Object *object_mesh = NewMesh();
|
2012-10-06 14:06:40 +00:00
|
|
|
#endif
|
2014-05-09 11:58:25 +09:00
|
|
|
Mesh *mesh = (Mesh *)object_mesh->data;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
mesh->totvert = group->totvert;
|
|
|
|
|
mesh->totedge = group->totedge;
|
2023-07-24 22:06:55 +02:00
|
|
|
mesh->faces_num = group->faces_num;
|
2014-08-08 22:29:02 +09:00
|
|
|
mesh->totloop = group->totloop;
|
2020-05-12 18:52:07 +02:00
|
|
|
mesh->totcol = group->materials.size();
|
2023-07-24 22:06:55 +02:00
|
|
|
BKE_mesh_face_offsets_ensure_alloc(mesh);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Mesh: Move positions to a generic attribute
**Changes**
As described in T93602, this patch removes all use of the `MVert`
struct, replacing it with a generic named attribute with the name
`"position"`, consistent with other geometry types.
Variable names have been changed from `verts` to `positions`, to align
with the attribute name and the more generic design (positions are not
vertices, they are just an attribute stored on the point domain).
This change is made possible by previous commits that moved all other
data out of `MVert` to runtime data or other generic attributes. What
remains is mostly a simple type change. Though, the type still shows up
859 times, so the patch is quite large.
One compromise is that now `CD_MASK_BAREMESH` now contains
`CD_PROP_FLOAT3`. With the general move towards generic attributes
over custom data types, we are removing use of these type masks anyway.
**Benefits**
The most obvious benefit is reduced memory usage and the benefits
that brings in memory-bound situations. `float3` is only 3 bytes, in
comparison to `MVert` which was 4. When there are millions of vertices
this starts to matter more.
The other benefits come from using a more generic type. Instead of
writing algorithms specifically for `MVert`, code can just use arrays
of vectors. This will allow eliminating many temporary arrays or
wrappers used to extract positions.
Many possible improvements aren't implemented in this patch, though
I did switch simplify or remove the process of creating temporary
position arrays in a few places.
The design clarity that "positions are just another attribute" brings
allows removing explicit copying of vertices in some procedural
operations-- they are just processed like most other attributes.
**Performance**
This touches so many areas that it's hard to benchmark exhaustively,
but I observed some areas as examples.
* The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster.
* The Spring splash screen went from ~4.3 to ~4.5 fps.
* The subdivision surface modifier/node was slightly faster
RNA access through Python may be slightly slower, since now we need
a name lookup instead of just a custom data type lookup for each index.
**Future Improvements**
* Remove uses of "vert_coords" functions:
* `BKE_mesh_vert_coords_alloc`
* `BKE_mesh_vert_coords_get`
* `BKE_mesh_vert_coords_apply{_with_mat4}`
* Remove more hidden copying of positions
* General simplification now possible in many areas
* Convert more code to C++ to use `float3` instead of `float[3]`
* Currently `reinterpret_cast` is used for those C-API functions
Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
|
|
|
float3 *vert_positions = (float3 *)CustomData_add_layer_named(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh->vert_data, CD_PROP_FLOAT3, CD_SET_DEFAULT, mesh->totvert, "position");
|
Mesh: Move edges to a generic attribute
Implements #95966, as the final step of #95965.
This commit changes the storage of mesh edge vertex indices from the
`MEdge` type to the generic `int2` attribute type. This follows the
general design for geometry and the attribute system, where the data
storage type and the usage semantics are separated.
The main benefit of the change is reduced memory usage-- the
requirements of storing mesh edges is reduced by 1/3. For example,
this saves 8MB on a 1 million vertex grid. This also gives performance
benefits to any memory-bound mesh processing algorithm that uses edges.
Another benefit is that all of the edge's vertex indices are
contiguous. In a few cases, it's helpful to process all of them as
`Span<int>` rather than `Span<int2>`. Similarly, the type is more
likely to match a generic format used by a library, or code that
shouldn't know about specific Blender `Mesh` types.
Various Notes:
- The `.edge_verts` name is used to reflect a mapping between domains,
similar to `.corner_verts`, etc. The period means that it the data
shouldn't change arbitrarily by the user or procedural operations.
- `edge[0]` is now used instead of `edge.v1`
- Signed integers are used instead of unsigned to reduce the mixing
of signed-ness, which can be error prone.
- All of the previously used core mesh data types (`MVert`, `MEdge`,
`MLoop`, `MPoly` are now deprecated. Only generic types are used).
- The `vec2i` DNA type is used in the few C files where necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106638
2023-04-17 13:47:41 +02:00
|
|
|
blender::int2 *edges = (blender::int2 *)CustomData_add_layer_named(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh->edge_data, CD_PROP_INT32_2D, CD_CONSTRUCT, mesh->totedge, ".edge_verts");
|
2023-07-24 22:06:55 +02:00
|
|
|
blender::MutableSpan<int> face_offsets = mesh->face_offsets_for_write();
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
int *corner_verts = (int *)CustomData_add_layer_named(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh->loop_data, CD_PROP_INT32, CD_SET_DEFAULT, mesh->totloop, ".corner_vert");
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
int *corner_edges = (int *)CustomData_add_layer_named(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh->loop_data, CD_PROP_INT32, CD_SET_DEFAULT, mesh->totloop, ".corner_edge");
|
2022-08-31 09:09:01 -05:00
|
|
|
int *material_indices = (int *)CustomData_add_layer_named(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh->face_data, CD_PROP_INT32, CD_SET_DEFAULT, mesh->faces_num, "material_index");
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 00:47:04 -05:00
|
|
|
blender::float2 *loopsuv[2] = {nullptr};
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
if (hasTex) {
|
|
|
|
|
// First UV layer
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 00:47:04 -05:00
|
|
|
loopsuv[0] = static_cast<blender::float2 *>(CustomData_add_layer_named(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh->loop_data, CD_PROP_FLOAT2, CD_SET_DEFAULT, mesh->totloop, uvNames[0]));
|
|
|
|
|
CustomData_set_layer_active(&mesh->loop_data, CD_PROP_FLOAT2, 0);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
// Second UV layer
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 00:47:04 -05:00
|
|
|
loopsuv[1] = static_cast<blender::float2 *>(CustomData_add_layer_named(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh->loop_data, CD_PROP_FLOAT2, CD_SET_DEFAULT, mesh->totloop, uvNames[1]));
|
|
|
|
|
CustomData_set_layer_active(&mesh->loop_data, CD_PROP_FLOAT2, 1);
|
2014-07-21 18:49:27 +09:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-21 18:49:27 +09:00
|
|
|
// colors and transparency (the latter represented by grayscale colors)
|
|
|
|
|
MLoopCol *colors = (MLoopCol *)CustomData_add_layer_named(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh->loop_data, CD_PROP_BYTE_COLOR, CD_SET_DEFAULT, mesh->totloop, "Color");
|
2014-07-21 18:49:27 +09:00
|
|
|
MLoopCol *transp = (MLoopCol *)CustomData_add_layer_named(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh->loop_data, CD_PROP_BYTE_COLOR, CD_SET_DEFAULT, mesh->totloop, "Alpha");
|
2022-12-15 14:18:57 -06:00
|
|
|
BKE_id_attributes_active_color_set(
|
2023-07-25 21:15:52 +02:00
|
|
|
&mesh->id, CustomData_get_layer_name(&mesh->loop_data, CD_PROP_BYTE_COLOR, 0));
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
mesh->mat = (Material **)MEM_mallocN(sizeof(Material *) * mesh->totcol, "MaterialList");
|
2021-02-17 06:19:01 +01:00
|
|
|
for (const auto item : group->materials.items()) {
|
2020-05-12 18:52:07 +02:00
|
|
|
Material *material = item.key;
|
|
|
|
|
const int matnr = item.value;
|
|
|
|
|
mesh->mat[matnr] = material;
|
|
|
|
|
if (material) {
|
|
|
|
|
id_us_plus(&material->id);
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-05-09 11:58:25 +09:00
|
|
|
////////////////////
|
|
|
|
|
// Data copy
|
|
|
|
|
////////////////////
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-24 22:06:55 +02:00
|
|
|
int vertex_index = 0, edge_index = 0, loop_index = 0, face_index = 0;
|
2014-08-08 22:29:02 +09:00
|
|
|
int visible_faces, visible_segments;
|
|
|
|
|
bool visible;
|
|
|
|
|
Strip::vertex_container::iterator v[3];
|
|
|
|
|
StrokeVertexRep *svRep[3];
|
|
|
|
|
Vec2r p;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
for (vector<StrokeRep *>::const_iterator it = group->strokes.begin(),
|
|
|
|
|
itend = group->strokes.end();
|
|
|
|
|
it != itend;
|
|
|
|
|
++it)
|
|
|
|
|
{
|
2020-05-12 18:52:07 +02:00
|
|
|
const int matnr = group->materials.lookup_default((*it)->getMaterial(), 0);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
vector<Strip *> &strips = (*it)->getStrips();
|
|
|
|
|
for (vector<Strip *>::const_iterator s = strips.begin(), send = strips.end(); s != send; ++s) {
|
|
|
|
|
Strip::vertex_container &strip_vertices = (*s)->vertices();
|
|
|
|
|
int strip_vertex_count = strip_vertices.size();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
// count visible faces and strip segments
|
|
|
|
|
test_strip_visibility(strip_vertices, &visible_faces, &visible_segments);
|
2019-05-31 22:51:19 +10:00
|
|
|
if (visible_faces == 0) {
|
2014-08-08 22:29:02 +09:00
|
|
|
continue;
|
2019-05-31 22:51:19 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
v[0] = strip_vertices.begin();
|
|
|
|
|
v[1] = v[0] + 1;
|
|
|
|
|
v[2] = v[0] + 2;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
visible = false;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-07-03 23:08:40 +10:00
|
|
|
// NOTE: Mesh generation in the following loop assumes stroke strips
|
2014-08-08 22:29:02 +09:00
|
|
|
// to be triangle strips.
|
|
|
|
|
for (int n = 2; n < strip_vertex_count; n++, v[0]++, v[1]++, v[2]++) {
|
|
|
|
|
svRep[0] = *(v[0]);
|
|
|
|
|
svRep[1] = *(v[1]);
|
|
|
|
|
svRep[2] = *(v[2]);
|
|
|
|
|
if (!test_triangle_visibility(svRep)) {
|
|
|
|
|
visible = false;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
if (!visible) {
|
|
|
|
|
// first vertex
|
Mesh: Move positions to a generic attribute
**Changes**
As described in T93602, this patch removes all use of the `MVert`
struct, replacing it with a generic named attribute with the name
`"position"`, consistent with other geometry types.
Variable names have been changed from `verts` to `positions`, to align
with the attribute name and the more generic design (positions are not
vertices, they are just an attribute stored on the point domain).
This change is made possible by previous commits that moved all other
data out of `MVert` to runtime data or other generic attributes. What
remains is mostly a simple type change. Though, the type still shows up
859 times, so the patch is quite large.
One compromise is that now `CD_MASK_BAREMESH` now contains
`CD_PROP_FLOAT3`. With the general move towards generic attributes
over custom data types, we are removing use of these type masks anyway.
**Benefits**
The most obvious benefit is reduced memory usage and the benefits
that brings in memory-bound situations. `float3` is only 3 bytes, in
comparison to `MVert` which was 4. When there are millions of vertices
this starts to matter more.
The other benefits come from using a more generic type. Instead of
writing algorithms specifically for `MVert`, code can just use arrays
of vectors. This will allow eliminating many temporary arrays or
wrappers used to extract positions.
Many possible improvements aren't implemented in this patch, though
I did switch simplify or remove the process of creating temporary
position arrays in a few places.
The design clarity that "positions are just another attribute" brings
allows removing explicit copying of vertices in some procedural
operations-- they are just processed like most other attributes.
**Performance**
This touches so many areas that it's hard to benchmark exhaustively,
but I observed some areas as examples.
* The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster.
* The Spring splash screen went from ~4.3 to ~4.5 fps.
* The subdivision surface modifier/node was slightly faster
RNA access through Python may be slightly slower, since now we need
a name lookup instead of just a custom data type lookup for each index.
**Future Improvements**
* Remove uses of "vert_coords" functions:
* `BKE_mesh_vert_coords_alloc`
* `BKE_mesh_vert_coords_get`
* `BKE_mesh_vert_coords_apply{_with_mat4}`
* Remove more hidden copying of positions
* General simplification now possible in many areas
* Convert more code to C++ to use `float3` instead of `float[3]`
* Currently `reinterpret_cast` is used for those C-API functions
Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
|
|
|
vert_positions[vertex_index][0] = svRep[0]->point2d()[0];
|
|
|
|
|
vert_positions[vertex_index][1] = svRep[0]->point2d()[1];
|
|
|
|
|
vert_positions[vertex_index][2] = get_stroke_vertex_z();
|
Refactor: Move normals out of MVert, lazy calculation
As described in T91186, this commit moves mesh vertex normals into a
contiguous array of float vectors in a custom data layer, how face
normals are currently stored.
The main interface is documented in `BKE_mesh.h`. Vertex and face
normals are now calculated on-demand and cached, retrieved with an
"ensure" function. Since the logical state of a mesh is now "has
normals when necessary", they can be retrieved from a `const` mesh.
The goal is to use on-demand calculation for all derived data, but
leave room for eager calculation for performance purposes (modifier
evaluation is threaded, but viewport data generation is not).
**Benefits**
This moves us closer to a SoA approach rather than the current AoS
paradigm. Accessing a contiguous `float3` is much more efficient than
retrieving data from a larger struct. The memory requirements for
accessing only normals or vertex locations are smaller, and at the
cost of more memory usage for just normals, they now don't have to
be converted between float and short, which also simplifies code
In the future, the remaining items can be removed from `MVert`,
leaving only `float3`, which has similar benefits (see T93602).
Removing the combination of derived and original data makes it
conceptually simpler to only calculate normals when necessary.
This is especially important now that we have more opportunities
for temporary meshes in geometry nodes.
**Performance**
In addition to the theoretical future performance improvements by
making `MVert == float3`, I've done some basic performance testing
on this patch directly. The data is fairly rough, but it gives an idea
about where things stand generally.
- Mesh line primitive 4m Verts: 1.16x faster (36 -> 31 ms),
showing that accessing just `MVert` is now more efficient.
- Spring Splash Screen: 1.03-1.06 -> 1.06-1.11 FPS, a very slight
change that at least shows there is no regression.
- Sprite Fright Snail Smoosh: 3.30-3.40 -> 3.42-3.50 FPS, a small
but observable speedup.
- Set Position Node with Scaled Normal: 1.36x faster (53 -> 39 ms),
shows that using normals in geometry nodes is faster.
- Normal Calculation 1.6m Vert Cube: 1.19x faster (25 -> 21 ms),
shows that calculating normals is slightly faster now.
- File Size of 1.6m Vert Cube: 1.03x smaller (214.7 -> 208.4 MB),
Normals are not saved in files, which can help with large meshes.
As for memory usage, it may be slightly more in some cases, but
I didn't observe any difference in the production files I tested.
**Tests**
Some modifiers and cycles test results need to be updated with this
commit, for two reasons:
- The subdivision surface modifier is not responsible for calculating
normals anymore. In master, the modifier creates different normals
than the result of the `Mesh` normal calculation, so this is a bug
fix.
- There are small differences in the results of some modifiers that
use normals because they are not converted to and from `short`
anymore.
**Future improvements**
- Remove `ModifierTypeInfo::dependsOnNormals`. Code in each modifier
already retrieves normals if they are needed anyway.
- Copy normals as part of a better CoW system for attributes.
- Make more areas use lazy instead of eager normal calculation.
- Remove `BKE_mesh_normals_tag_dirty` in more places since that is
now the default state of a new mesh.
- Possibly apply a similar change to derived face corner normals.
Differential Revision: https://developer.blender.org/D12770
2022-01-13 14:37:58 -06:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
++vertex_index;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
// second vertex
|
Mesh: Move positions to a generic attribute
**Changes**
As described in T93602, this patch removes all use of the `MVert`
struct, replacing it with a generic named attribute with the name
`"position"`, consistent with other geometry types.
Variable names have been changed from `verts` to `positions`, to align
with the attribute name and the more generic design (positions are not
vertices, they are just an attribute stored on the point domain).
This change is made possible by previous commits that moved all other
data out of `MVert` to runtime data or other generic attributes. What
remains is mostly a simple type change. Though, the type still shows up
859 times, so the patch is quite large.
One compromise is that now `CD_MASK_BAREMESH` now contains
`CD_PROP_FLOAT3`. With the general move towards generic attributes
over custom data types, we are removing use of these type masks anyway.
**Benefits**
The most obvious benefit is reduced memory usage and the benefits
that brings in memory-bound situations. `float3` is only 3 bytes, in
comparison to `MVert` which was 4. When there are millions of vertices
this starts to matter more.
The other benefits come from using a more generic type. Instead of
writing algorithms specifically for `MVert`, code can just use arrays
of vectors. This will allow eliminating many temporary arrays or
wrappers used to extract positions.
Many possible improvements aren't implemented in this patch, though
I did switch simplify or remove the process of creating temporary
position arrays in a few places.
The design clarity that "positions are just another attribute" brings
allows removing explicit copying of vertices in some procedural
operations-- they are just processed like most other attributes.
**Performance**
This touches so many areas that it's hard to benchmark exhaustively,
but I observed some areas as examples.
* The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster.
* The Spring splash screen went from ~4.3 to ~4.5 fps.
* The subdivision surface modifier/node was slightly faster
RNA access through Python may be slightly slower, since now we need
a name lookup instead of just a custom data type lookup for each index.
**Future Improvements**
* Remove uses of "vert_coords" functions:
* `BKE_mesh_vert_coords_alloc`
* `BKE_mesh_vert_coords_get`
* `BKE_mesh_vert_coords_apply{_with_mat4}`
* Remove more hidden copying of positions
* General simplification now possible in many areas
* Convert more code to C++ to use `float3` instead of `float[3]`
* Currently `reinterpret_cast` is used for those C-API functions
Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
|
|
|
vert_positions[vertex_index][0] = svRep[1]->point2d()[0];
|
|
|
|
|
vert_positions[vertex_index][1] = svRep[1]->point2d()[1];
|
|
|
|
|
vert_positions[vertex_index][2] = get_stroke_vertex_z();
|
Refactor: Move normals out of MVert, lazy calculation
As described in T91186, this commit moves mesh vertex normals into a
contiguous array of float vectors in a custom data layer, how face
normals are currently stored.
The main interface is documented in `BKE_mesh.h`. Vertex and face
normals are now calculated on-demand and cached, retrieved with an
"ensure" function. Since the logical state of a mesh is now "has
normals when necessary", they can be retrieved from a `const` mesh.
The goal is to use on-demand calculation for all derived data, but
leave room for eager calculation for performance purposes (modifier
evaluation is threaded, but viewport data generation is not).
**Benefits**
This moves us closer to a SoA approach rather than the current AoS
paradigm. Accessing a contiguous `float3` is much more efficient than
retrieving data from a larger struct. The memory requirements for
accessing only normals or vertex locations are smaller, and at the
cost of more memory usage for just normals, they now don't have to
be converted between float and short, which also simplifies code
In the future, the remaining items can be removed from `MVert`,
leaving only `float3`, which has similar benefits (see T93602).
Removing the combination of derived and original data makes it
conceptually simpler to only calculate normals when necessary.
This is especially important now that we have more opportunities
for temporary meshes in geometry nodes.
**Performance**
In addition to the theoretical future performance improvements by
making `MVert == float3`, I've done some basic performance testing
on this patch directly. The data is fairly rough, but it gives an idea
about where things stand generally.
- Mesh line primitive 4m Verts: 1.16x faster (36 -> 31 ms),
showing that accessing just `MVert` is now more efficient.
- Spring Splash Screen: 1.03-1.06 -> 1.06-1.11 FPS, a very slight
change that at least shows there is no regression.
- Sprite Fright Snail Smoosh: 3.30-3.40 -> 3.42-3.50 FPS, a small
but observable speedup.
- Set Position Node with Scaled Normal: 1.36x faster (53 -> 39 ms),
shows that using normals in geometry nodes is faster.
- Normal Calculation 1.6m Vert Cube: 1.19x faster (25 -> 21 ms),
shows that calculating normals is slightly faster now.
- File Size of 1.6m Vert Cube: 1.03x smaller (214.7 -> 208.4 MB),
Normals are not saved in files, which can help with large meshes.
As for memory usage, it may be slightly more in some cases, but
I didn't observe any difference in the production files I tested.
**Tests**
Some modifiers and cycles test results need to be updated with this
commit, for two reasons:
- The subdivision surface modifier is not responsible for calculating
normals anymore. In master, the modifier creates different normals
than the result of the `Mesh` normal calculation, so this is a bug
fix.
- There are small differences in the results of some modifiers that
use normals because they are not converted to and from `short`
anymore.
**Future improvements**
- Remove `ModifierTypeInfo::dependsOnNormals`. Code in each modifier
already retrieves normals if they are needed anyway.
- Copy normals as part of a better CoW system for attributes.
- Make more areas use lazy instead of eager normal calculation.
- Remove `BKE_mesh_normals_tag_dirty` in more places since that is
now the default state of a new mesh.
- Possibly apply a similar change to derived face corner normals.
Differential Revision: https://developer.blender.org/D12770
2022-01-13 14:37:58 -06:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
++vertex_index;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
// first edge
|
Mesh: Move edges to a generic attribute
Implements #95966, as the final step of #95965.
This commit changes the storage of mesh edge vertex indices from the
`MEdge` type to the generic `int2` attribute type. This follows the
general design for geometry and the attribute system, where the data
storage type and the usage semantics are separated.
The main benefit of the change is reduced memory usage-- the
requirements of storing mesh edges is reduced by 1/3. For example,
this saves 8MB on a 1 million vertex grid. This also gives performance
benefits to any memory-bound mesh processing algorithm that uses edges.
Another benefit is that all of the edge's vertex indices are
contiguous. In a few cases, it's helpful to process all of them as
`Span<int>` rather than `Span<int2>`. Similarly, the type is more
likely to match a generic format used by a library, or code that
shouldn't know about specific Blender `Mesh` types.
Various Notes:
- The `.edge_verts` name is used to reflect a mapping between domains,
similar to `.corner_verts`, etc. The period means that it the data
shouldn't change arbitrarily by the user or procedural operations.
- `edge[0]` is now used instead of `edge.v1`
- Signed integers are used instead of unsigned to reduce the mixing
of signed-ness, which can be error prone.
- All of the previously used core mesh data types (`MVert`, `MEdge`,
`MLoop`, `MPoly` are now deprecated. Only generic types are used).
- The `vec2i` DNA type is used in the few C files where necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106638
2023-04-17 13:47:41 +02:00
|
|
|
edges[edge_index][0] = vertex_index - 2;
|
|
|
|
|
edges[edge_index][1] = vertex_index - 1;
|
2014-08-08 22:29:02 +09:00
|
|
|
++edge_index;
|
|
|
|
|
}
|
|
|
|
|
visible = true;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
// vertex
|
Mesh: Move positions to a generic attribute
**Changes**
As described in T93602, this patch removes all use of the `MVert`
struct, replacing it with a generic named attribute with the name
`"position"`, consistent with other geometry types.
Variable names have been changed from `verts` to `positions`, to align
with the attribute name and the more generic design (positions are not
vertices, they are just an attribute stored on the point domain).
This change is made possible by previous commits that moved all other
data out of `MVert` to runtime data or other generic attributes. What
remains is mostly a simple type change. Though, the type still shows up
859 times, so the patch is quite large.
One compromise is that now `CD_MASK_BAREMESH` now contains
`CD_PROP_FLOAT3`. With the general move towards generic attributes
over custom data types, we are removing use of these type masks anyway.
**Benefits**
The most obvious benefit is reduced memory usage and the benefits
that brings in memory-bound situations. `float3` is only 3 bytes, in
comparison to `MVert` which was 4. When there are millions of vertices
this starts to matter more.
The other benefits come from using a more generic type. Instead of
writing algorithms specifically for `MVert`, code can just use arrays
of vectors. This will allow eliminating many temporary arrays or
wrappers used to extract positions.
Many possible improvements aren't implemented in this patch, though
I did switch simplify or remove the process of creating temporary
position arrays in a few places.
The design clarity that "positions are just another attribute" brings
allows removing explicit copying of vertices in some procedural
operations-- they are just processed like most other attributes.
**Performance**
This touches so many areas that it's hard to benchmark exhaustively,
but I observed some areas as examples.
* The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster.
* The Spring splash screen went from ~4.3 to ~4.5 fps.
* The subdivision surface modifier/node was slightly faster
RNA access through Python may be slightly slower, since now we need
a name lookup instead of just a custom data type lookup for each index.
**Future Improvements**
* Remove uses of "vert_coords" functions:
* `BKE_mesh_vert_coords_alloc`
* `BKE_mesh_vert_coords_get`
* `BKE_mesh_vert_coords_apply{_with_mat4}`
* Remove more hidden copying of positions
* General simplification now possible in many areas
* Convert more code to C++ to use `float3` instead of `float[3]`
* Currently `reinterpret_cast` is used for those C-API functions
Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
|
|
|
vert_positions[vertex_index][0] = svRep[2]->point2d()[0];
|
|
|
|
|
vert_positions[vertex_index][1] = svRep[2]->point2d()[1];
|
|
|
|
|
vert_positions[vertex_index][2] = get_stroke_vertex_z();
|
2012-06-16 21:49:52 +00:00
|
|
|
++vertex_index;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
// edges
|
Mesh: Move edges to a generic attribute
Implements #95966, as the final step of #95965.
This commit changes the storage of mesh edge vertex indices from the
`MEdge` type to the generic `int2` attribute type. This follows the
general design for geometry and the attribute system, where the data
storage type and the usage semantics are separated.
The main benefit of the change is reduced memory usage-- the
requirements of storing mesh edges is reduced by 1/3. For example,
this saves 8MB on a 1 million vertex grid. This also gives performance
benefits to any memory-bound mesh processing algorithm that uses edges.
Another benefit is that all of the edge's vertex indices are
contiguous. In a few cases, it's helpful to process all of them as
`Span<int>` rather than `Span<int2>`. Similarly, the type is more
likely to match a generic format used by a library, or code that
shouldn't know about specific Blender `Mesh` types.
Various Notes:
- The `.edge_verts` name is used to reflect a mapping between domains,
similar to `.corner_verts`, etc. The period means that it the data
shouldn't change arbitrarily by the user or procedural operations.
- `edge[0]` is now used instead of `edge.v1`
- Signed integers are used instead of unsigned to reduce the mixing
of signed-ness, which can be error prone.
- All of the previously used core mesh data types (`MVert`, `MEdge`,
`MLoop`, `MPoly` are now deprecated. Only generic types are used).
- The `vec2i` DNA type is used in the few C files where necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106638
2023-04-17 13:47:41 +02:00
|
|
|
edges[edge_index][0] = vertex_index - 1;
|
|
|
|
|
edges[edge_index][1] = vertex_index - 3;
|
2012-06-16 21:49:52 +00:00
|
|
|
++edge_index;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Mesh: Move edges to a generic attribute
Implements #95966, as the final step of #95965.
This commit changes the storage of mesh edge vertex indices from the
`MEdge` type to the generic `int2` attribute type. This follows the
general design for geometry and the attribute system, where the data
storage type and the usage semantics are separated.
The main benefit of the change is reduced memory usage-- the
requirements of storing mesh edges is reduced by 1/3. For example,
this saves 8MB on a 1 million vertex grid. This also gives performance
benefits to any memory-bound mesh processing algorithm that uses edges.
Another benefit is that all of the edge's vertex indices are
contiguous. In a few cases, it's helpful to process all of them as
`Span<int>` rather than `Span<int2>`. Similarly, the type is more
likely to match a generic format used by a library, or code that
shouldn't know about specific Blender `Mesh` types.
Various Notes:
- The `.edge_verts` name is used to reflect a mapping between domains,
similar to `.corner_verts`, etc. The period means that it the data
shouldn't change arbitrarily by the user or procedural operations.
- `edge[0]` is now used instead of `edge.v1`
- Signed integers are used instead of unsigned to reduce the mixing
of signed-ness, which can be error prone.
- All of the previously used core mesh data types (`MVert`, `MEdge`,
`MLoop`, `MPoly` are now deprecated. Only generic types are used).
- The `vec2i` DNA type is used in the few C files where necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106638
2023-04-17 13:47:41 +02:00
|
|
|
edges[edge_index][0] = vertex_index - 1;
|
|
|
|
|
edges[edge_index][1] = vertex_index - 2;
|
2014-08-08 22:29:02 +09:00
|
|
|
++edge_index;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
// poly
|
2023-07-24 22:06:55 +02:00
|
|
|
face_offsets[face_index] = loop_index;
|
2022-08-31 09:09:01 -05:00
|
|
|
*material_indices = matnr;
|
|
|
|
|
++material_indices;
|
2023-07-24 22:06:55 +02:00
|
|
|
++face_index;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
// Even and odd loops connect triangles vertices differently
|
|
|
|
|
bool is_odd = n % 2;
|
|
|
|
|
// loops
|
|
|
|
|
if (is_odd) {
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
corner_verts[0] = vertex_index - 1;
|
|
|
|
|
corner_edges[0] = edge_index - 2;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
corner_verts[1] = vertex_index - 3;
|
|
|
|
|
corner_edges[1] = edge_index - 3;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
corner_verts[2] = vertex_index - 2;
|
|
|
|
|
corner_edges[2] = edge_index - 1;
|
2014-08-08 22:29:02 +09:00
|
|
|
}
|
|
|
|
|
else {
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
corner_verts[0] = vertex_index - 1;
|
|
|
|
|
corner_edges[0] = edge_index - 1;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
corner_verts[1] = vertex_index - 2;
|
|
|
|
|
corner_edges[1] = edge_index - 3;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
corner_verts[2] = vertex_index - 3;
|
|
|
|
|
corner_edges[2] = edge_index - 2;
|
2014-08-08 22:29:02 +09:00
|
|
|
}
|
Mesh: Replace MLoop struct with generic attributes
Implements #102359.
Split the `MLoop` struct into two separate integer arrays called
`corner_verts` and `corner_edges`, referring to the vertex each corner
is attached to and the next edge around the face at each corner. These
arrays can be sliced to give access to the edges or vertices in a face.
Then they are often referred to as "poly_verts" or "poly_edges".
The main benefits are halving the necessary memory bandwidth when only
one array is used and simplifications from using regular integer indices
instead of a special-purpose struct.
The commit also starts a renaming from "loop" to "corner" in mesh code.
Like the other mesh struct of array refactors, forward compatibility is
kept by writing files with the older format. This will be done until 4.0
to ease the transition process.
Looking at a small portion of the patch should give a good impression
for the rest of the changes. I tried to make the changes as small as
possible so it's easy to tell the correctness from the diff. Though I
found Blender developers have been very inventive over the last decade
when finding different ways to loop over the corners in a face.
For performance, nearly every piece of code that deals with `Mesh` is
slightly impacted. Any algorithm that is memory bottle-necked should
see an improvement. For example, here is a comparison of interpolating
a vertex float attribute to face corners (Ryzen 3700x):
**Before** (Average: 3.7 ms, Min: 3.4 ms)
```
threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) {
for (const int64_t i : range) {
dst[i] = src[loops[i].v];
}
});
```
**After** (Average: 2.9 ms, Min: 2.6 ms)
```
array_utils::gather(src, corner_verts, dst);
```
That's an improvement of 28% to the average timings, and it's also a
simplification, since an index-based routine can be used instead.
For more examples using the new arrays, see the design task.
Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
|
|
|
corner_verts += 3;
|
|
|
|
|
corner_edges += 3;
|
2014-08-08 22:29:02 +09:00
|
|
|
loop_index += 3;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
// UV
|
|
|
|
|
if (hasTex) {
|
|
|
|
|
// First UV layer (loopsuv[0]) has no tips (texCoord(0)).
|
|
|
|
|
// Second UV layer (loopsuv[1]) has tips: (texCoord(1)).
|
|
|
|
|
for (int L = 0; L < 2; L++) {
|
|
|
|
|
if (is_odd) {
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 00:47:04 -05:00
|
|
|
loopsuv[L][0][0] = svRep[2]->texCoord(L).x();
|
|
|
|
|
loopsuv[L][0][1] = svRep[2]->texCoord(L).y();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 00:47:04 -05:00
|
|
|
loopsuv[L][1][0] = svRep[0]->texCoord(L).x();
|
|
|
|
|
loopsuv[L][1][1] = svRep[0]->texCoord(L).y();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 00:47:04 -05:00
|
|
|
loopsuv[L][2][0] = svRep[1]->texCoord(L).x();
|
|
|
|
|
loopsuv[L][2][1] = svRep[1]->texCoord(L).y();
|
2014-08-08 22:29:02 +09:00
|
|
|
}
|
|
|
|
|
else {
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 00:47:04 -05:00
|
|
|
loopsuv[L][0][0] = svRep[2]->texCoord(L).x();
|
|
|
|
|
loopsuv[L][0][1] = svRep[2]->texCoord(L).y();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 00:47:04 -05:00
|
|
|
loopsuv[L][1][0] = svRep[1]->texCoord(L).x();
|
|
|
|
|
loopsuv[L][1][1] = svRep[1]->texCoord(L).y();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 00:47:04 -05:00
|
|
|
loopsuv[L][2][0] = svRep[0]->texCoord(L).x();
|
|
|
|
|
loopsuv[L][2][1] = svRep[0]->texCoord(L).y();
|
2014-08-08 22:29:02 +09:00
|
|
|
}
|
|
|
|
|
loopsuv[L] += 3;
|
2014-05-03 18:51:53 +09:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
|
2015-10-10 18:44:19 +02:00
|
|
|
// colors and alpha transparency. vertex colors are in sRGB
|
|
|
|
|
// space by convention, so convert from linear
|
|
|
|
|
float rgba[3][4];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-10-10 18:44:19 +02:00
|
|
|
for (int i = 0; i < 3; i++) {
|
|
|
|
|
copy_v3fl_v3db(rgba[i], &svRep[i]->color()[0]);
|
|
|
|
|
rgba[i][3] = svRep[i]->alpha();
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
if (is_odd) {
|
2015-10-10 18:44:19 +02:00
|
|
|
linearrgb_to_srgb_uchar4(&colors[0].r, rgba[2]);
|
|
|
|
|
linearrgb_to_srgb_uchar4(&colors[1].r, rgba[0]);
|
|
|
|
|
linearrgb_to_srgb_uchar4(&colors[2].r, rgba[1]);
|
2014-08-08 22:29:02 +09:00
|
|
|
}
|
|
|
|
|
else {
|
2015-10-10 18:44:19 +02:00
|
|
|
linearrgb_to_srgb_uchar4(&colors[0].r, rgba[2]);
|
|
|
|
|
linearrgb_to_srgb_uchar4(&colors[1].r, rgba[1]);
|
|
|
|
|
linearrgb_to_srgb_uchar4(&colors[2].r, rgba[0]);
|
2014-08-08 22:29:02 +09:00
|
|
|
}
|
|
|
|
|
transp[0].r = transp[0].g = transp[0].b = colors[0].a;
|
|
|
|
|
transp[1].r = transp[1].g = transp[1].b = colors[1].a;
|
|
|
|
|
transp[2].r = transp[2].g = transp[2].b = colors[2].a;
|
|
|
|
|
colors += 3;
|
|
|
|
|
transp += 3;
|
2012-06-16 21:49:52 +00:00
|
|
|
}
|
2014-08-08 22:29:02 +09:00
|
|
|
} // loop over strip vertices
|
|
|
|
|
} // loop over strips
|
2020-05-12 18:52:07 +02:00
|
|
|
} // loop over strokes
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-02-05 11:23:58 +01:00
|
|
|
BKE_object_materials_test(freestyle_bmain, object_mesh, (ID *)mesh);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-08-08 22:29:02 +09:00
|
|
|
#if 0 // XXX
|
|
|
|
|
BLI_assert(mesh->totvert == vertex_index);
|
|
|
|
|
BLI_assert(mesh->totedge == edge_index);
|
|
|
|
|
BLI_assert(mesh->totloop == loop_index);
|
2015-02-05 14:03:01 +01:00
|
|
|
BKE_mesh_validate(mesh, true, true);
|
2012-06-16 21:49:52 +00:00
|
|
|
#endif
|
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
2008-12-01 21:30:44 +00:00
|
|
|
}
|
|
|
|
|
|
2012-10-06 14:06:40 +00:00
|
|
|
// A replacement of BKE_object_add() for better performance.
|
2012-12-18 00:51:25 +00:00
|
|
|
Object *BlenderStrokeRenderer::NewMesh() const
|
|
|
|
|
{
|
2012-10-06 14:06:40 +00:00
|
|
|
Object *ob;
|
|
|
|
|
char name[MAX_ID_NAME];
|
2022-09-25 17:04:52 +10:00
|
|
|
uint mesh_id = get_stroke_mesh_id();
|
2012-10-06 14:06:40 +00:00
|
|
|
|
2023-05-09 12:50:37 +10:00
|
|
|
SNPRINTF(name, "0%08xOB", mesh_id);
|
2013-04-23 22:40:13 +00:00
|
|
|
ob = BKE_object_add_only_object(freestyle_bmain, OB_MESH, name);
|
2023-05-09 12:50:37 +10:00
|
|
|
SNPRINTF(name, "0%08xME", mesh_id);
|
2013-04-23 22:40:13 +00:00
|
|
|
ob->data = BKE_mesh_add(freestyle_bmain, name);
|
2012-10-06 14:06:40 +00:00
|
|
|
|
2019-09-02 14:31:19 +02:00
|
|
|
Collection *collection_master = freestyle_scene->master_collection;
|
Collections and groups unification
OVERVIEW
* In 2.7 terminology, all layers and groups are now collection datablocks.
* These collections are nestable, linkable, instanceable, overrideable, ..
which opens up new ways to set up scenes and link + override data.
* Viewport/render visibility and selectability are now a part of the collection
and shared across all view layers and linkable.
* View layers define which subset of the scene collection hierarchy is excluded
for each. For many workflows one view layer can be used, these are more of an
advanced feature now.
OUTLINER
* The outliner now has a "View Layer" display mode instead of "Collections",
which can display the collections and/or objects in the view layer.
* In this display mode, collections can be excluded with the right click menu.
These will then be greyed out and their objects will be excluded.
* To view collections not linked to any scene, the "Blender File" display mode
can be used, with the new filtering option to just see Colleciton datablocks.
* The outliner right click menus for collections and objects were reorganized.
* Drag and drop still needs to be improved. Like before, dragging the icon or
text gives different results, we'll unify this later.
LINKING AND OVERRIDES
* Collections can now be linked into the scene without creating an instance,
with the link/append operator or from the collections view in the outliner.
* Collections can get static overrides with the right click menu in the outliner,
but this is rather unreliable and not clearly communicated at the moment.
* We still need to improve the make override operator to turn collection instances
into collections with overrides directly in the scene.
PERFORMANCE
* We tried to make performance not worse than before and improve it in some
cases. The main thing that's still a bit slower is multiple scenes, we have to
change the layer syncing to only updated affected scenes.
* Collections keep a list of their parent collections for faster incremental
updates in syncing and caching.
* View layer bases are now in a object -> base hash to avoid quadratic time
lookups internally and in API functions like visible_get().
VERSIONING
* Compatibility with 2.7 files should be improved due to the new visibility
controls. Of course users may not want to set up their scenes differently
now to avoid having separate layers and groups.
* Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero
files. There's a few things which are know to be not quite compatible, like
nested layer collections inside groups.
* The versioning code for 2.8 files is quite complicated, and isolated behind
#ifdef so it can be removed at the end of the release cycle.
KNOWN ISSUES
* The G-key group operators in the 3D viewport were left mostly as is, they
need to be modified still to fit better.
* Same for the groups panel in the object properties. This needs to be updated
still, or perhaps replaced by something better.
* Collections must all have a unique name. Less restrictive namespacing is to
be done later, we'll have to see how important this is as all objects within
the collections must also have a unique name anyway.
* Full scene copy and delete scene are exactly doing the right thing yet.
Differential Revision: https://developer.blender.org/D3383
https://code.blender.org/2018/05/collections-and-groups/
2018-04-30 15:57:22 +02:00
|
|
|
BKE_collection_object_add(freestyle_bmain, collection_master, ob);
|
2017-11-03 14:36:49 +01:00
|
|
|
DEG_graph_tag_relations_update(freestyle_depsgraph);
|
2014-01-15 17:42:01 +06:00
|
|
|
|
2017-11-03 14:36:49 +01:00
|
|
|
DEG_graph_id_tag_update(freestyle_bmain,
|
|
|
|
|
freestyle_depsgraph,
|
|
|
|
|
&ob->id,
|
2018-12-06 17:52:37 +01:00
|
|
|
ID_RECALC_TRANSFORM | ID_RECALC_GEOMETRY | ID_RECALC_ANIMATION);
|
2012-10-06 14:06:40 +00:00
|
|
|
|
|
|
|
|
return ob;
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-18 15:23:59 +02:00
|
|
|
Render *BlenderStrokeRenderer::RenderScene(Render * /*re*/, bool render)
|
2012-12-18 00:51:25 +00:00
|
|
|
{
|
2013-03-07 23:17:23 +00:00
|
|
|
Camera *camera = (Camera *)freestyle_scene->camera->data;
|
2019-05-31 22:51:19 +10:00
|
|
|
if (camera->clip_end < _z) {
|
2019-02-16 12:21:44 +11:00
|
|
|
camera->clip_end = _z + _z_delta * 100.0f;
|
2019-05-31 22:51:19 +10:00
|
|
|
}
|
2013-01-03 23:27:20 +00:00
|
|
|
#if 0
|
|
|
|
|
if (G.debug & G_DEBUG_FREESTYLE) {
|
2019-02-16 12:21:44 +11:00
|
|
|
cout << "clip_start " << camera->clip_start << ", clip_end " << camera->clip_end << endl;
|
2013-01-03 23:27:20 +00:00
|
|
|
}
|
|
|
|
|
#endif
|
2010-02-16 02:10:27 +00:00
|
|
|
|
2017-09-12 11:27:22 +05:00
|
|
|
Render *freestyle_render = RE_NewSceneRender(freestyle_scene);
|
2020-08-18 15:51:32 +02:00
|
|
|
DEG_graph_relations_update(freestyle_depsgraph);
|
2010-02-08 02:19:17 +00:00
|
|
|
|
2015-01-17 22:33:13 +09:00
|
|
|
RE_RenderFreestyleStrokes(
|
|
|
|
|
freestyle_render, freestyle_bmain, freestyle_scene, render && get_stroke_count() > 0);
|
2013-04-18 12:11:50 +00:00
|
|
|
|
2010-02-15 00:07:15 +00:00
|
|
|
return freestyle_render;
|
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
2008-12-01 21:30:44 +00:00
|
|
|
}
|
2013-04-09 00:46:49 +00:00
|
|
|
|
|
|
|
|
} /* namespace Freestyle */
|