archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
4b188bb08cf5aaae3c68ab57bbcfa037eef1ac10
blender-archive/source/blender/blenkernel/BKE_persistent_data_handle.hh

130 lines
3.1 KiB
C++
Raw Normal View History

Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
/*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
Code Style: use "#pragma once" in source directory This replaces header include guards with `#pragma once`. A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`), because they are used in other places. This patch has been generated by P1561 followed by `make format`. Differential Revision: https://developer.blender.org/D8466
2020-08-07 09:50:34 +02:00
#pragma once
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
/** \file
* \ingroup bke
*
* A PersistentDataHandle is a weak reference to some data in a Blender file. The handle itself is
* just a number. A PersistentDataHandleMap is used to convert between handles and the actual data.
*/
#include "BLI_map.hh"
#include "DNA_ID.h"
struct Object;
namespace blender::bke {
class PersistentDataHandleMap;
class PersistentDataHandle {
private:
/* Negative values indicate that the handle is "empty". */
int32_t handle_;
friend PersistentDataHandleMap;
protected:
PersistentDataHandle(int handle) : handle_(handle)
{
}
public:
PersistentDataHandle() : handle_(-1)
{
}
friend bool operator==(const PersistentDataHandle &a, const PersistentDataHandle &b)
{
return a.handle_ == b.handle_;
}
friend bool operator!=(const PersistentDataHandle &a, const PersistentDataHandle &b)
{
return !(a == b);
}
friend std::ostream &operator<<(std::ostream &stream, const PersistentDataHandle &a)
{
stream << a.handle_;
return stream;
}
uint64_t hash() const
{
Cleanup: use C++ style casts in various places
2020-08-07 18:24:59 +02:00
return static_cast<uint64_t>(handle_);
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
}
};
class PersistentIDHandle : public PersistentDataHandle {
friend PersistentDataHandleMap;
using PersistentDataHandle::PersistentDataHandle;
};
class PersistentObjectHandle : public PersistentIDHandle {
friend PersistentDataHandleMap;
using PersistentIDHandle::PersistentIDHandle;
};
class PersistentDataHandleMap {
private:
Particles: spawn particles on mesh surface
2020-07-23 22:30:05 +02:00
Map<int32_t, ID *> id_by_handle_;
Map<ID *, int32_t> handle_by_id_;
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
public:
Particles: spawn particles on mesh surface
2020-07-23 22:30:05 +02:00
void add(int32_t handle, ID &id)
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
{
BLI_assert(handle >= 0);
handle_by_id_.add(&id, handle);
id_by_handle_.add(handle, &id);
}
Particles: spawn particles on mesh surface
2020-07-23 22:30:05 +02:00
PersistentIDHandle lookup(ID *id) const
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
{
const int handle = handle_by_id_.lookup_default(id, -1);
return PersistentIDHandle(handle);
}
Particles: spawn particles on mesh surface
2020-07-23 22:30:05 +02:00
PersistentObjectHandle lookup(Object *object) const
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
{
Particles: spawn particles on mesh surface
2020-07-23 22:30:05 +02:00
const int handle = handle_by_id_.lookup_default((ID *)object, -1);
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
return PersistentObjectHandle(handle);
}
Particles: spawn particles on mesh surface
2020-07-23 22:30:05 +02:00
ID *lookup(const PersistentIDHandle &handle) const
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
{
Particles: spawn particles on mesh surface
2020-07-23 22:30:05 +02:00
ID *id = id_by_handle_.lookup_default(handle.handle_, nullptr);
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
return id;
}
Particles: spawn particles on mesh surface
2020-07-23 22:30:05 +02:00
Object *lookup(const PersistentObjectHandle &handle) const
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
{
Particles: spawn particles on mesh surface
2020-07-23 22:30:05 +02:00
ID *id = this->lookup((const PersistentIDHandle &)handle);
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
if (id == nullptr) {
return nullptr;
}
if (GS(id->name) != ID_OB) {
return nullptr;
}
Particles: spawn particles on mesh surface
2020-07-23 22:30:05 +02:00
return (Object *)id;
Particles: initial object socket and emitter node support Object sockets work now, but only the new Object Transforms and the Particle Mesh Emitter node use it. The emitter does not actually use the mesh surface yet. Instead, new particles are just emitted around the origin of the object. Internally, handles to object data blocks are passed around in the network, instead of raw object pointers. Using handles has a couple of benefits: * The caller of the function has control over which handles can be resolved and therefore limit access to specific data. The set of data blocks that is accessed by a node tree should be known statically. This is necessary for a proper integration with the dependency graph. * When the pointer to an object changes (e.g. after restarting Blender), all handles are still valid. * When an object is deleted, the handle is invalidated without causing crashes. * The handle is just an integer that can be stored per particle and can be cached easily. The mapping between handles and their corresponding data blocks is stored in the Simulation data block.
2020-07-21 17:20:05 +02:00
}
};
} // namespace blender::bke
Copy Permalink