Files
test2/source/blender/freestyle/intern/system/RenderMonitor.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

59 lines
945 B
C
Raw Normal View History

/* SPDX-FileCopyrightText: 2023 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
#pragma once
/** \file
* \ingroup freestyle
* \brief Classes defining the basic "Iterator" design pattern
*/
#include "render_types.h"
#ifdef WITH_CXX_GUARDEDALLOC
# include "MEM_guardedalloc.h"
#endif
Attempt to fix a potential name conflict between Freestyle and the compositor. A crash in the Freestyle renderer was reported by Ton on IRC with a stack trace below. Note that #2 is in Freestyle, whereas #1 is in the compositor. The problem was observed in a debug build on OS X 10.7 (gcc 4.2, openmp disabled, no llvm). ---------------------------------------------------------------------- Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 [Switching to process 72386 thread 0xf303] 0x0000000100c129f3 in NodeBase::~NodeBase (this=0x10e501c80) at COM_NodeBase.cpp:43 43 delete (this->m_outputsockets.back()); Current language: auto; currently c++ (gdb) where #0 0x0000000100c129f3 in NodeBase::~NodeBase (this=0x10e501c80) at COM_NodeBase.cpp:43 #1 0x0000000100c29066 in Node::~Node (this=0x10e501c80) at COM_Node.h:49 #2 0x000000010089c273 in NodeShape::~NodeShape (this=0x10e501c80) at NodeShape.cpp:43 #3 0x000000010089910b in NodeGroup::destroy (this=0x10e501da0) at NodeGroup.cpp:61 #4 0x00000001008990cd in NodeGroup::destroy (this=0x10e5014b0) at NodeGroup.cpp:59 #5 0x00000001008990cd in NodeGroup::destroy (this=0x114e18da0) at NodeGroup.cpp:59 #6 0x00000001007e6602 in Controller::ClearRootNode (this=0x114e19640) at Controller.cpp:329 #7 0x00000001007ea52e in Controller::LoadMesh (this=0x114e19640, re=0x10aba4638, srl=0x1140f5258) at Controller.cpp:302 #8 0x00000001008030ad in prepare (re=0x10aba4638, srl=0x1140f5258) at FRS_freestyle.cpp:302 #9 0x000000010080457a in FRS_do_stroke_rendering (re=0x10aba4638, srl=0x1140f5258) at FRS_freestyle.cpp:600 #10 0x00000001006aeb9d in add_freestyle (re=0x10aba4638) at pipeline.c:1584 #11 0x00000001006aceb7 in do_render_3d (re=0x10aba4638) at pipeline.c:1094 #12 0x00000001006ae061 in do_render_fields_blur_3d (re=0x10aba4638) at pipeline.c:1367 #13 0x00000001006afa16 in do_render_composite_fields_blur_3d (re=0x10aba4638) at pipeline.c:1815 #14 0x00000001006b04e4 in do_render_all_options (re=0x10aba4638) at pipeline.c:2021 ---------------------------------------------------------------------- Apparently a name conflict between the two Blender modules is taking place. The present commit hence intends to address it by putting all the Freestyle C++ classes in the namespace 'Freestyle'. This revision will also prevent potential name conflicts with other Blender modules in the future. Special thanks to Lukas Toenne for the help with C++ namespace.
2013-04-09 00:46:49 +00:00
namespace Freestyle {
class RenderMonitor {
public:
inline RenderMonitor(Render *re)
{
_re = re;
}
virtual ~RenderMonitor() {}
Fix for [#35245] Freestyle getting stuck on view map creation + memory leaks. There were two issues: - Line visibility computations are very slow in the case of the provided .blend file, which gave an impression that the rendering process got stuck. The slowness can be explained by the present data structures used for the line visibility computations, together with the specific mesh distribution of the test scene. At the moment Freestyle uses a regular grid in the 2D image coordinate system to divide tris/quads into small groups in order to accelerate the line visibility computations. On the other hand, the test scene is populated a big plane (made of one quad) and a moderately detailed mesh object (22K tris). The scale of the latter mesh is animated from nearly zero to about 0.2 to make the object show up over time. When the scale is nearly equal to zero, all the tris concentrate in one grid cell, so essentially there is no performance gain from the grid data structure optimized for speed. It looks like a better grid data structure (possibly based on adaptive grid refinement) is necessary to genuinely address the identified performance issue. For now the progress bar of Blender is employed to better inform users of the amount of work done in the line visibility computations. - A crash was caused by an excessive memory allocation request. The X and Y dimensions of the grid data structure are determined based on the average area of mesh faces in the given scene. When the big plane in the test scene is excluded from the rendering, the average area is almost zero (on the order of 1e-5). As a result of this extremely small average area, the X and Y dimensions were set to a very large number, causing a fatal memory allocation error. The present revision has introduced a hard upper limit to the dimensions of the grid data structure to avoid this kind of numerical instability.
2013-05-19 00:56:40 +00:00
inline void setInfo(string info)
{
if (_re && !info.empty()) {
_re->i.infostr = info.c_str();
_re->stats_draw(&_re->i);
_re->i.infostr = nullptr;
Fix for [#35245] Freestyle getting stuck on view map creation + memory leaks. There were two issues: - Line visibility computations are very slow in the case of the provided .blend file, which gave an impression that the rendering process got stuck. The slowness can be explained by the present data structures used for the line visibility computations, together with the specific mesh distribution of the test scene. At the moment Freestyle uses a regular grid in the 2D image coordinate system to divide tris/quads into small groups in order to accelerate the line visibility computations. On the other hand, the test scene is populated a big plane (made of one quad) and a moderately detailed mesh object (22K tris). The scale of the latter mesh is animated from nearly zero to about 0.2 to make the object show up over time. When the scale is nearly equal to zero, all the tris concentrate in one grid cell, so essentially there is no performance gain from the grid data structure optimized for speed. It looks like a better grid data structure (possibly based on adaptive grid refinement) is necessary to genuinely address the identified performance issue. For now the progress bar of Blender is employed to better inform users of the amount of work done in the line visibility computations. - A crash was caused by an excessive memory allocation request. The X and Y dimensions of the grid data structure are determined based on the average area of mesh faces in the given scene. When the big plane in the test scene is excluded from the rendering, the average area is almost zero (on the order of 1e-5). As a result of this extremely small average area, the X and Y dimensions were set to a very large number, causing a fatal memory allocation error. The present revision has introduced a hard upper limit to the dimensions of the grid data structure to avoid this kind of numerical instability.
2013-05-19 00:56:40 +00:00
}
}
inline void progress(float i)
{
if (_re) {
_re->progress(i);
}
Fix for [#35245] Freestyle getting stuck on view map creation + memory leaks. There were two issues: - Line visibility computations are very slow in the case of the provided .blend file, which gave an impression that the rendering process got stuck. The slowness can be explained by the present data structures used for the line visibility computations, together with the specific mesh distribution of the test scene. At the moment Freestyle uses a regular grid in the 2D image coordinate system to divide tris/quads into small groups in order to accelerate the line visibility computations. On the other hand, the test scene is populated a big plane (made of one quad) and a moderately detailed mesh object (22K tris). The scale of the latter mesh is animated from nearly zero to about 0.2 to make the object show up over time. When the scale is nearly equal to zero, all the tris concentrate in one grid cell, so essentially there is no performance gain from the grid data structure optimized for speed. It looks like a better grid data structure (possibly based on adaptive grid refinement) is necessary to genuinely address the identified performance issue. For now the progress bar of Blender is employed to better inform users of the amount of work done in the line visibility computations. - A crash was caused by an excessive memory allocation request. The X and Y dimensions of the grid data structure are determined based on the average area of mesh faces in the given scene. When the big plane in the test scene is excluded from the rendering, the average area is almost zero (on the order of 1e-5). As a result of this extremely small average area, the X and Y dimensions were set to a very large number, causing a fatal memory allocation error. The present revision has introduced a hard upper limit to the dimensions of the grid data structure to avoid this kind of numerical instability.
2013-05-19 00:56:40 +00:00
}
inline bool testBreak()
{
return _re && _re->test_break();
}
protected:
Render *_re;
#ifdef WITH_CXX_GUARDEDALLOC
MEM_CXX_CLASS_ALLOC_FUNCS("Freestyle:RenderMonitor")
#endif
};
Attempt to fix a potential name conflict between Freestyle and the compositor. A crash in the Freestyle renderer was reported by Ton on IRC with a stack trace below. Note that #2 is in Freestyle, whereas #1 is in the compositor. The problem was observed in a debug build on OS X 10.7 (gcc 4.2, openmp disabled, no llvm). ---------------------------------------------------------------------- Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 [Switching to process 72386 thread 0xf303] 0x0000000100c129f3 in NodeBase::~NodeBase (this=0x10e501c80) at COM_NodeBase.cpp:43 43 delete (this->m_outputsockets.back()); Current language: auto; currently c++ (gdb) where #0 0x0000000100c129f3 in NodeBase::~NodeBase (this=0x10e501c80) at COM_NodeBase.cpp:43 #1 0x0000000100c29066 in Node::~Node (this=0x10e501c80) at COM_Node.h:49 #2 0x000000010089c273 in NodeShape::~NodeShape (this=0x10e501c80) at NodeShape.cpp:43 #3 0x000000010089910b in NodeGroup::destroy (this=0x10e501da0) at NodeGroup.cpp:61 #4 0x00000001008990cd in NodeGroup::destroy (this=0x10e5014b0) at NodeGroup.cpp:59 #5 0x00000001008990cd in NodeGroup::destroy (this=0x114e18da0) at NodeGroup.cpp:59 #6 0x00000001007e6602 in Controller::ClearRootNode (this=0x114e19640) at Controller.cpp:329 #7 0x00000001007ea52e in Controller::LoadMesh (this=0x114e19640, re=0x10aba4638, srl=0x1140f5258) at Controller.cpp:302 #8 0x00000001008030ad in prepare (re=0x10aba4638, srl=0x1140f5258) at FRS_freestyle.cpp:302 #9 0x000000010080457a in FRS_do_stroke_rendering (re=0x10aba4638, srl=0x1140f5258) at FRS_freestyle.cpp:600 #10 0x00000001006aeb9d in add_freestyle (re=0x10aba4638) at pipeline.c:1584 #11 0x00000001006aceb7 in do_render_3d (re=0x10aba4638) at pipeline.c:1094 #12 0x00000001006ae061 in do_render_fields_blur_3d (re=0x10aba4638) at pipeline.c:1367 #13 0x00000001006afa16 in do_render_composite_fields_blur_3d (re=0x10aba4638) at pipeline.c:1815 #14 0x00000001006b04e4 in do_render_all_options (re=0x10aba4638) at pipeline.c:2021 ---------------------------------------------------------------------- Apparently a name conflict between the two Blender modules is taking place. The present commit hence intends to address it by putting all the Freestyle C++ classes in the namespace 'Freestyle'. This revision will also prevent potential name conflicts with other Blender modules in the future. Special thanks to Lukas Toenne for the help with C++ namespace.
2013-04-09 00:46:49 +00:00
} /* namespace Freestyle */