做物件散布做到深夜的人十个有九个都被克隆体卡到怀疑人生。上个月刚好在整理一个植被场景克隆体数量直接飙到十多万视口旋转一下电脑风扇的声音比渲染器的轰鸣还大。实在被逼得没办法我用 C4D Python 写了一整套小工具核心就是标题里那三件事克隆体缓存操作、批量“割草”、以及每次操作都能安全回滚的事件机制。如果你也遇到过克隆一多就卡成 PPT、想批量清理又怕手滑删错、删完才发现回不去的窘境这篇就把我踩过的坑和能直接抄的代码都摊开给你看。先解释一下“割草代码”是什么。它不是真的去模拟一台割草机而是借用了割草这个动作场景里散布了大量克隆体视觉上就像一整片草地。你要做的操作是把其中一部分克隆体按规则“割”掉比如把高于某条线的裁剪掉、把球体范围内的清空、或者按比例抽稀。剩下没被割的克隆体继续留在场景里。“支持事件回滚”指的是工具会把每一次割草动作包装成一个可回滚的事件触发之后能把场景恢复成割之前的状态不需要一次次手动撤销也不会因为中间缓存刷新就丢掉恢复能力。好直接按我实际的开发过程来拆。1. 项目拆解克隆体缓存、割草与事件回滚到底在解决什么1.1 克隆体缓存操作操作的到底是什么很多刚玩 C4D Python 的人会把“缓存”理解成一个单纯的内存概念其实在 C4D 的对象体系里缓存是一个实实在在的场景对象。克隆对象在被计算之后会生成一个 cache你可以通过GetCache()把它拿出来。这个缓存里装的东西根据克隆模式不同可能是普通对象、实例对象也可能是多边形网格。我们常说的“缓存操作”主要有三种读取缓存、刷新缓存、烘焙缓存。读取缓存很好理解就是拿到克隆生成的完整对象列表方便后续对单个克隆体做判断和修改。刷新缓存是当克隆参数变化之后手动标记缓存失效让 C4D 重新计算。烘焙缓存是更有意思的一步它通过MCOMMAND_MAKEEDITABLE这类建模命令把处于“生成状态”的克隆体真正落成场景里的可编辑几何。为什么这三件事放在一起值得做因为大量克隆体一旦原始参数改了或者视口刷新之前你对克隆体做的任何手工修改都会被冲掉。只有先“烤”成真实几何后续的割草操作才有意义否则你删掉的只是临时缓存C4D 下一秒就给你重新长出来。1.2 割草代码的本质批量过滤加批量删除割草本质上就是两件事按条件筛选目标再对筛选结果做批量删除。听起来简单但放在十多万量级的克隆体上筛选逻辑的效率和安全性就很重要了。常见的筛选规则有三个维度空间位置、数量比例、属性状态。空间位置适用于“这个区域不要草了”这类需求比如以某台“割草机”对象为圆心把半径内的克隆体清空或者把所有高于路面的部分裁掉。数量比例适合做密度抽稀比如场景里有十万棵草要变成五万棵随机保留一半然后用参数控制种子值保证每次的结果可以复现。属性状态则看克隆体的可视状态、渲染标志位或者顶点色等信息处于对应状态的克隆体才会被选中。我一开始图省事直接遍历整个缓存列表逐个判断、逐个删除。结果十万级克隆体一次要跑小半分钟而且 C4D 的事件通知刷得非常密集卡得界面像是死机。后来改成两阶段操作先快速筛选把要删的引用集中到一个列表里再统一批量处理性能一下从“不可用”变成“秒级”。1.3 事件回滚为什么值得单独设计有读者可能会问C4D 本来就有撤销为什么还要自己写一个回滚系统这个问题我开发的时候也问过自己踩了几次坑之后才明白差别在哪。原生撤销是“操作级”的它记录的是你对文档做过哪些修改。但割草整套流程涉及多个步骤先烘焙缓存、再删除克隆、再刷一遍视口。这中间每一步都可能成为独立的撤销步骤用户想回到“割草之前”这个语义状态得手动多按几次撤销而且一旦中途刷新过缓存某些克隆体已经从场景里消失了原生撤销不一定能完整恢复它们的层级关系。此外原生撤销对对象层级和缓存状态的记录非常底层恢复之后不一定能还原到你想要的状态。比如你删掉的是克隆缓存里的某个子对象撤销时它的父层级可能已经因为缓存刷新变成全新的对象引用整个断掉。自定义事件回滚的核心价值就是让我们可以在一个更高的语义层面上记录“谁被删了、删之前它挂在哪、删完之后参数是什么”恢复的时候按记录把对象重新挂回去不依赖 C4D 那一刻的缓存状态。2. 架构思路与技术选型这些决策背后的理由2.1 为什么选 C4D Python 而不是 C 插件先聊一个很多人在立项时会纠结的问题做这种效率工具用 Python 脚本会不会性能不够我的判断是要看瓶颈在哪。割草性能的瓶颈主要在对象遍历和批量删除的 UI 刷新节奏上这部分 Python 确实不如 C 快但差距没有想象中大而且 Python 和 C 底层调的是同一套对象 API。真正决定成败的是算法设计比如避免在循环里反复请求文档级操作、减少EventAdd()的调用次数。选 Python 还有一个比较现实的原因迭代快。给场景做工具需求经常变上午要按高度割下午就要改成按半径割晚上可能又要加一个随机抽稀按钮。C 版本改一次要重新编译Python 脚本改完直接重跑这点效率优势在实际开发里比那点性能差距值钱得多。2.2 缓存读取和刷新的三条路径在 C4D Python 里操作克隆体缓存我实际用到的是这三条路径各有各的适用场景。第一条是GetCache()适合在克隆对象已经被计算过之后把缓存对象直接拿出来遍历。需要注意的是如果缓存还没生成这个方法会返回None。所以在脚本开头一定要判断否则后面取子对象列表时会直接报错。第二条是SetDirty()加EventAdd()适合手动强制刷新。克隆参数改了之后C4D 不一定立刻重建缓存尤其在一些非主线程的调用场景里你得主动把克隆对象标记为脏对象再发事件让主线程去更新。这里的坑是脏标记的粒度全部标记会引发整个文档大范围重新计算能精确到DIRTYFLAGS_DATA就尽量别用DIRTYFLAGS_ALL。第三条是建模命令MCOMMAND_MAKEEDITABLE适合做烘焙。它相当于把“生成状态”的克隆体转换成场景里的一系列真实对象。这一步做完之前 cache 里的临时对象就变成了可以在对象管理器里直接选中、直接删除的正式几何。割草工具运行的先后顺序里这一条是最重要的前置条件。2.3 割草算法的设计维度我把割草筛选逻辑设计成了可插拔的模式而不是写死在函数里。核心思路是保留一个统一的入口内部根据不同的模式分发到不同的筛选函数。每个筛选函数只做一件事输入克隆体列表输出需要删除的列表。def collect_victims(clones, mode, params): if mode height: return filter_by_height(clones, params[level], params[keep_low]) if mode radius: return filter_by_radius(clones, params[center], params[radius]) if mode ratio: return filter_by_ratio(clones, params[keep], params[seed]) return []这种写法看起来平淡但在实际开发里非常值钱。因为割草规则大概率会越加越多而每个规则之间的组合逻辑很容易把人绕晕。先用单一模式跑通后续要做“高度加半径”的复合模式时只需要再包一层组合器不用回头改主流程。筛选函数本身也有讲究。以半径筛选为例计算克隆体位置时最好用GetMg().off拿到的是世界坐标直接和圆心求距离不会有局部坐标换算的麻烦。而且要注意拿到的克隆体有可能是实例对象这些对象的世界矩阵一样有效不必区分类型。2.4 事件回滚的分层设计回滚这块我没有做成一套复杂的框架只做了两层。第一层是原生撤销的桥接。每次割草动作我都会把整个流程包进StartUndo和EndUndo之间。这样即使用户不想用我的自定义回滚一次 CtrlZ 也能撤销完整动作这是最低限度的安全网。第二层是自定义事件栈。我定义了一个RollbackSession在开始割草时创建一个会话把所有被删除对象的引用、它们原来的父对象、原来的排列位置都记录进去。执行回滚时按记录反向把对象重新挂回文档并按需恢复参数。这层设计不依赖 C4D 当时是否已经重建了缓存因此能处理原生撤销处理不了的场景。两层设计有一个共同的前提每次操作都要在内存里完整记录“之前的样子”。这是回滚系统的地基不能省。3. 核心代码实现从烤缓存到割草再到回滚3.1 克隆体缓存读取封装先上最基础的一段读缓存并提取克隆体列表。我封装成一个函数输入克隆对象输出克隆体列表和状态信息方便上层判断。import c4d CLONER_ID c4d.O1010471 def get_clone_list(cloner): 从克隆对象取缓存并整理成扁平的克隆体列表 if cloner is None or not cloner.CheckType(CLONER_ID): return [] cache cloner.GetCache() if cache is None: return [] result [] stack list(cache.GetChildren()) # 缓存里可能还有嵌套层级用栈做一次扁平化 while stack: obj stack.pop() result.append(obj) stack.extend(obj.GetChildren()) return result这里有个小细节值得说。直接用cache.GetChildren()只拿到第一层但真实项目里克隆体下面可能还挂着实例组、矩阵组这类嵌套结构所以我把所有层级都扁平化了一遍。你也许觉得多此一举但我在实际场景里遇到过某个克隆体下面还带两个子对象如果不做递归展开后面筛选时会漏掉一大片。另一个细节是CheckType(CLONER_ID)。c4d.O1010471是克隆对象的固定类型 ID用这种方式可以防止用户误选了一个普通的空对象导致脚本直接崩溃。检查类型这件事在写任何工具脚本时都值得当成默认习惯。3.2 烘焙缓存割草前必做的动作接上面说的割草前一定要先把克隆体烤成真实几何。我用建模命令MCOMMAND_MAKEEDITABLE实现并包进原生撤销栈里。def bake_cloner(doc, cloner): 把克隆对象转换为可编辑几何成功返回True if cloner is None: return False doc.StartUndo() try: res c4d.SendModelingCommand( c4d.MCOMMAND_MAKEEDITABLE, [cloner], c4d.MODELINGCOMMANDMODE_ALL, doc, c4d.MODELINGCOMMANDFLAGS_UNDO ) finally: doc.EndUndo() if res: c4d.EventAdd() return bool(res)有两点必须说明。第一SendModelingCommand的第三个参数是MODELINGCOMMANDMODE_ALL意思是作用于整个对象而不是只作用于点线面子层级。对克隆对象来说这个参数其实就一个合理选择但写习惯了会顺手复制还是要注意。第二MODELINGCOMMANDFLAGS_UNDO是让这次建模操作进入撤销栈的关键不加这个 flag用户事后就只能靠我的自定义回滚灵活性差很多。烘焙这一步本身也可能有耗时因为大量克隆体要真正生成网格对象。如果场景里本身用的是实例模式烘焙前的对象数量其实不大但烘焙后会显著增加。我的建议是烘焙前先确认一下克隆体数量级超过二三十万个的场景要提醒用户导出前再操作避免在视口交互阶段就撑爆内存。3.3 割草逻辑的完整实现烤完缓存就可以开始割草了。下面给出高度筛选和半径筛选两个最常用的实现。高度筛选适合把地面以上所有过高的“草丛尖儿”裁掉半径筛选适合清理某个障碍物周围的植被。def filter_by_height(clones, level, keep_lowTrue): 按高度筛选默认保留低于level的部分割掉高于level的部分 victims [] for obj in clones: if obj is None: continue y obj.GetMg().off.y if keep_low and y level: victims.append(obj) elif not keep_low and y level: victims.append(obj) return victims def filter_by_radius(clones, center, radius): 按到中心的距离筛选半径范围内的全部割掉 victims [] r2 radius * radius # 用平方距离避免反复开方 for obj in clones: if obj is None: continue diff obj.GetMg().off - center if diff.x * diff.x diff.y * diff.y diff.z * diff.z r2: victims.append(obj) return victims这里有个性能技巧判断距离时不直接开平方而是统一用距离的平方和半径的平方做比较。十万个对象看似只省一个Sqrt但乘在一起能明显缩短整段脚本的运行时间。我自己实测下来十万级对象能差出小半秒在这个处理量级上很可观了。使用的时候把筛选结果交给统一删除函数一次性放进撤销栈再批量删除def mow_objects(doc, victims): if not victims: return 0 doc.StartUndo() for obj in victims: if obj.GetDocument() is None: continue doc.AddUndo(c4d.UNDOTYPE_DELETE, obj) obj.Remove() doc.EndUndo() c4d.EventAdd() return len(victims)注意obj.GetDocument() is None这个判断。在实际使用中同一个缓存里可能出现嵌套对象父对象被删掉之后子对象会自动脱离文档如果不跳过它们后面Remove()调用就会收到无效对象引用轻则报错重则污染撤销栈。3.4 可回滚事件管理器的实现割草逻辑本身不难难的是回滚。我实现的RollbackSession是这样的class RollbackSession: def __init__(self, doc, labelmow): self.doc doc self.label label self.deleted [] def record_delete(self, obj): parent obj.GetParent() pred obj.GetPred() self.deleted.append({obj: obj, parent: parent, pred: pred}) def delete(self, obj): self.record_delete(obj) obj.Remove() def rollback(self): if not self.doc: return 0 count 0 # 反向恢复保证嵌套关系正确 for rec in reversed(self.deleted): obj rec[obj] pred rec[pred] parent rec[parent] try: if pred is not None and pred.GetDocument() self.doc: obj.InsertObject(pred) elif parent is not None: obj.InsertUnderLast(parent) else: self.doc.InsertObject(obj) count 1 except RuntimeError: pass self.deleted.clear() c4d.EventAdd() return count回滚时的关键一步是把对象重新挂回原来的层级。我优先检查pred删除时的前序兄弟对象是否还活着如果还活着就插回原位如果它已经被删了就退回父对象用InsertUnderLast挂到父级最后面。这个兜底逻辑保证了即使原位置上的前序对象也已经没了对象还是能回到一个合理的位置不会丢失。实际使用的时候回滚前我还建议把文档里刚发生的事件通知先停掉等对象全部恢复完再一次EventAdd()。原因是恢复过程中每个InsertObject都会触发视口刷新几十个对象还好几百上千个对象就会明显卡顿。用一次统一的刷新替代多次增量刷新是这类批量恢复的基本优化。4. 实测表现、踩坑记录与常见问题速查4.1 不同克隆数量级下的实测表现我在几个不同规模的场景里跑过这套工具把大概数据放在这里供参考。注意这些数据会随机器配置变化但相对趋势是稳定可靠的。克隆体数量烘焙耗时高度割草耗时删除回滚耗时2 万约 3 秒约 0.2 秒约 0.1 秒8 万约 9 秒约 0.8 秒约 0.4 秒15 万约 18 秒约 1.5 秒约 1 秒实际感知最明显的是删除耗时远低于筛选耗时。也就是说真正的性能瓶颈在遍历判断对象位置这个阶段不在 C4D 对象管理。这坚定了我在算法上优化的方向能用平方距离就不开方能用一次遍历就不分多次能在内存里做完的筛选就不要反复往文档层发事件。4.2 我踩过的几个大坑第一个坑是没烘焙就删缓存子对象。一开始我在没做 Make Editable 的情况下直接遍历缓存并删除结果删完下一秒 C4D 刷新克隆体全回来了。当时的心理状态可以说是崩溃的。后来才意识到克隆缓存是一个“生成的临时结果”它不掌握在用户手里你删掉的东西只属于那一帧的快照。解决方案就是烘焙前置尽量把“生成状态”变成“落地的可编辑对象”。第二个坑是SetDirty(c4d.DIRTYFLAGS_ALL)导致的连锁刷新。为了图省事我刷新缓存时全部标记结果整个文档里所有被污染的对象都跟着重建了一遍一个简单的参数调整变成了全场景重计算。后来我改成只对当前克隆对象做局部脏标记缩放到单对象粒度刷新成本立刻降下来了。第三个坑是循环里频繁调用c4d.EventAdd()。写第一个版本时我每删一个克隆体就通知一次 UI结果十多万对象删下来界面基本处于半冻结状态。后来改成先收集完所有要删的对象最后统一EventAdd()就再也没有卡死的问题。这个经验对所有批量操作都适用事件通知是给用户看的不是给每一个中间步骤看的。4.3 常见问题速查问题现象可能原因处理方式GetCache()返回None克隆体还没计算过可能在非主线程脚本里执行先调用一次c4d.DrawViews()或手动刷新视口再重新读取删除后克隆体又自动恢复没有执行烘焙删的是临时缓存操作前执行 Make Editable 并确认结果对象存在回滚后对象层级乱掉原位置的pred对象已被删除没做兜底判断改用父对象插入或记录更完整的对象路径信息脚本执行后半途卡死批量操作过程中反复EventAdd()改为收集完成后统一刷新一次EventAdd()结束删除无效对象引用崩溃父对象删除后子对象自动脱离文档删除前检查obj.GetDocument() is None这套速查表是我后续维护工具时自己最常用的索引。说实话每一条背后都是至少半小时的排查代价写进文档比重新踩一遍划算太多。5. 一点额外的使用建议最后再把两件实操里最有价值的小事说透。第一件烘焙和割草尽量做成两个按钮而不是一个按钮执行到底。因为烘焙本身就是一个耗时操作有时候用户只想把克隆体落地并不想立刻清理任何东西。分开之后用户可以分步骤决定结果也更容易定位问题发生在烘焙阶段还是删除阶段。第二件给回滚事件写一个清晰的日志。我在RollbackSession里加了一个label参数配合一个简单的控制台输出执行一次割草就会打出“Mow: 删除 3261 个对象可回滚”。实际使用中这行日志帮我排查了无数次“为什么数量对不上”的问题因为筛选结果每次都能直接和场景里的实际变化对上。工具写到这里说到底就是三个能力能安全地操作克隆体缓存、能按规则批量割草、能在出问题时把锅甩给回滚事件。如果你也总被大量克隆体磨得没脾气建议先从最后那层回滚保护写起有了安全网动刀的手才敢放得开。
做物件散布做到深夜的人十个有九个都被克隆体卡到怀疑人生。上个月刚好在整理一个植被场景克隆体数量直接飙到十多万视口旋转一下电脑风扇的声音比渲染器的轰鸣还大。实在被逼得没办法我用 C4D Python 写了一整套小工具核心就是标题里那三件事克隆体缓存操作、批量“割草”、以及每次操作都能安全回滚的事件机制。如果你也遇到过克隆一多就卡成 PPT、想批量清理又怕手滑删错、删完才发现回不去的窘境这篇就把我踩过的坑和能直接抄的代码都摊开给你看。先解释一下“割草代码”是什么。它不是真的去模拟一台割草机而是借用了割草这个动作场景里散布了大量克隆体视觉上就像一整片草地。你要做的操作是把其中一部分克隆体按规则“割”掉比如把高于某条线的裁剪掉、把球体范围内的清空、或者按比例抽稀。剩下没被割的克隆体继续留在场景里。“支持事件回滚”指的是工具会把每一次割草动作包装成一个可回滚的事件触发之后能把场景恢复成割之前的状态不需要一次次手动撤销也不会因为中间缓存刷新就丢掉恢复能力。好直接按我实际的开发过程来拆。1. 项目拆解克隆体缓存、割草与事件回滚到底在解决什么1.1 克隆体缓存操作操作的到底是什么很多刚玩 C4D Python 的人会把“缓存”理解成一个单纯的内存概念其实在 C4D 的对象体系里缓存是一个实实在在的场景对象。克隆对象在被计算之后会生成一个 cache你可以通过GetCache()把它拿出来。这个缓存里装的东西根据克隆模式不同可能是普通对象、实例对象也可能是多边形网格。我们常说的“缓存操作”主要有三种读取缓存、刷新缓存、烘焙缓存。读取缓存很好理解就是拿到克隆生成的完整对象列表方便后续对单个克隆体做判断和修改。刷新缓存是当克隆参数变化之后手动标记缓存失效让 C4D 重新计算。烘焙缓存是更有意思的一步它通过MCOMMAND_MAKEEDITABLE这类建模命令把处于“生成状态”的克隆体真正落成场景里的可编辑几何。为什么这三件事放在一起值得做因为大量克隆体一旦原始参数改了或者视口刷新之前你对克隆体做的任何手工修改都会被冲掉。只有先“烤”成真实几何后续的割草操作才有意义否则你删掉的只是临时缓存C4D 下一秒就给你重新长出来。1.2 割草代码的本质批量过滤加批量删除割草本质上就是两件事按条件筛选目标再对筛选结果做批量删除。听起来简单但放在十多万量级的克隆体上筛选逻辑的效率和安全性就很重要了。常见的筛选规则有三个维度空间位置、数量比例、属性状态。空间位置适用于“这个区域不要草了”这类需求比如以某台“割草机”对象为圆心把半径内的克隆体清空或者把所有高于路面的部分裁掉。数量比例适合做密度抽稀比如场景里有十万棵草要变成五万棵随机保留一半然后用参数控制种子值保证每次的结果可以复现。属性状态则看克隆体的可视状态、渲染标志位或者顶点色等信息处于对应状态的克隆体才会被选中。我一开始图省事直接遍历整个缓存列表逐个判断、逐个删除。结果十万级克隆体一次要跑小半分钟而且 C4D 的事件通知刷得非常密集卡得界面像是死机。后来改成两阶段操作先快速筛选把要删的引用集中到一个列表里再统一批量处理性能一下从“不可用”变成“秒级”。1.3 事件回滚为什么值得单独设计有读者可能会问C4D 本来就有撤销为什么还要自己写一个回滚系统这个问题我开发的时候也问过自己踩了几次坑之后才明白差别在哪。原生撤销是“操作级”的它记录的是你对文档做过哪些修改。但割草整套流程涉及多个步骤先烘焙缓存、再删除克隆、再刷一遍视口。这中间每一步都可能成为独立的撤销步骤用户想回到“割草之前”这个语义状态得手动多按几次撤销而且一旦中途刷新过缓存某些克隆体已经从场景里消失了原生撤销不一定能完整恢复它们的层级关系。此外原生撤销对对象层级和缓存状态的记录非常底层恢复之后不一定能还原到你想要的状态。比如你删掉的是克隆缓存里的某个子对象撤销时它的父层级可能已经因为缓存刷新变成全新的对象引用整个断掉。自定义事件回滚的核心价值就是让我们可以在一个更高的语义层面上记录“谁被删了、删之前它挂在哪、删完之后参数是什么”恢复的时候按记录把对象重新挂回去不依赖 C4D 那一刻的缓存状态。2. 架构思路与技术选型这些决策背后的理由2.1 为什么选 C4D Python 而不是 C 插件先聊一个很多人在立项时会纠结的问题做这种效率工具用 Python 脚本会不会性能不够我的判断是要看瓶颈在哪。割草性能的瓶颈主要在对象遍历和批量删除的 UI 刷新节奏上这部分 Python 确实不如 C 快但差距没有想象中大而且 Python 和 C 底层调的是同一套对象 API。真正决定成败的是算法设计比如避免在循环里反复请求文档级操作、减少EventAdd()的调用次数。选 Python 还有一个比较现实的原因迭代快。给场景做工具需求经常变上午要按高度割下午就要改成按半径割晚上可能又要加一个随机抽稀按钮。C 版本改一次要重新编译Python 脚本改完直接重跑这点效率优势在实际开发里比那点性能差距值钱得多。2.2 缓存读取和刷新的三条路径在 C4D Python 里操作克隆体缓存我实际用到的是这三条路径各有各的适用场景。第一条是GetCache()适合在克隆对象已经被计算过之后把缓存对象直接拿出来遍历。需要注意的是如果缓存还没生成这个方法会返回None。所以在脚本开头一定要判断否则后面取子对象列表时会直接报错。第二条是SetDirty()加EventAdd()适合手动强制刷新。克隆参数改了之后C4D 不一定立刻重建缓存尤其在一些非主线程的调用场景里你得主动把克隆对象标记为脏对象再发事件让主线程去更新。这里的坑是脏标记的粒度全部标记会引发整个文档大范围重新计算能精确到DIRTYFLAGS_DATA就尽量别用DIRTYFLAGS_ALL。第三条是建模命令MCOMMAND_MAKEEDITABLE适合做烘焙。它相当于把“生成状态”的克隆体转换成场景里的一系列真实对象。这一步做完之前 cache 里的临时对象就变成了可以在对象管理器里直接选中、直接删除的正式几何。割草工具运行的先后顺序里这一条是最重要的前置条件。2.3 割草算法的设计维度我把割草筛选逻辑设计成了可插拔的模式而不是写死在函数里。核心思路是保留一个统一的入口内部根据不同的模式分发到不同的筛选函数。每个筛选函数只做一件事输入克隆体列表输出需要删除的列表。def collect_victims(clones, mode, params): if mode height: return filter_by_height(clones, params[level], params[keep_low]) if mode radius: return filter_by_radius(clones, params[center], params[radius]) if mode ratio: return filter_by_ratio(clones, params[keep], params[seed]) return []这种写法看起来平淡但在实际开发里非常值钱。因为割草规则大概率会越加越多而每个规则之间的组合逻辑很容易把人绕晕。先用单一模式跑通后续要做“高度加半径”的复合模式时只需要再包一层组合器不用回头改主流程。筛选函数本身也有讲究。以半径筛选为例计算克隆体位置时最好用GetMg().off拿到的是世界坐标直接和圆心求距离不会有局部坐标换算的麻烦。而且要注意拿到的克隆体有可能是实例对象这些对象的世界矩阵一样有效不必区分类型。2.4 事件回滚的分层设计回滚这块我没有做成一套复杂的框架只做了两层。第一层是原生撤销的桥接。每次割草动作我都会把整个流程包进StartUndo和EndUndo之间。这样即使用户不想用我的自定义回滚一次 CtrlZ 也能撤销完整动作这是最低限度的安全网。第二层是自定义事件栈。我定义了一个RollbackSession在开始割草时创建一个会话把所有被删除对象的引用、它们原来的父对象、原来的排列位置都记录进去。执行回滚时按记录反向把对象重新挂回文档并按需恢复参数。这层设计不依赖 C4D 当时是否已经重建了缓存因此能处理原生撤销处理不了的场景。两层设计有一个共同的前提每次操作都要在内存里完整记录“之前的样子”。这是回滚系统的地基不能省。3. 核心代码实现从烤缓存到割草再到回滚3.1 克隆体缓存读取封装先上最基础的一段读缓存并提取克隆体列表。我封装成一个函数输入克隆对象输出克隆体列表和状态信息方便上层判断。import c4d CLONER_ID c4d.O1010471 def get_clone_list(cloner): 从克隆对象取缓存并整理成扁平的克隆体列表 if cloner is None or not cloner.CheckType(CLONER_ID): return [] cache cloner.GetCache() if cache is None: return [] result [] stack list(cache.GetChildren()) # 缓存里可能还有嵌套层级用栈做一次扁平化 while stack: obj stack.pop() result.append(obj) stack.extend(obj.GetChildren()) return result这里有个小细节值得说。直接用cache.GetChildren()只拿到第一层但真实项目里克隆体下面可能还挂着实例组、矩阵组这类嵌套结构所以我把所有层级都扁平化了一遍。你也许觉得多此一举但我在实际场景里遇到过某个克隆体下面还带两个子对象如果不做递归展开后面筛选时会漏掉一大片。另一个细节是CheckType(CLONER_ID)。c4d.O1010471是克隆对象的固定类型 ID用这种方式可以防止用户误选了一个普通的空对象导致脚本直接崩溃。检查类型这件事在写任何工具脚本时都值得当成默认习惯。3.2 烘焙缓存割草前必做的动作接上面说的割草前一定要先把克隆体烤成真实几何。我用建模命令MCOMMAND_MAKEEDITABLE实现并包进原生撤销栈里。def bake_cloner(doc, cloner): 把克隆对象转换为可编辑几何成功返回True if cloner is None: return False doc.StartUndo() try: res c4d.SendModelingCommand( c4d.MCOMMAND_MAKEEDITABLE, [cloner], c4d.MODELINGCOMMANDMODE_ALL, doc, c4d.MODELINGCOMMANDFLAGS_UNDO ) finally: doc.EndUndo() if res: c4d.EventAdd() return bool(res)有两点必须说明。第一SendModelingCommand的第三个参数是MODELINGCOMMANDMODE_ALL意思是作用于整个对象而不是只作用于点线面子层级。对克隆对象来说这个参数其实就一个合理选择但写习惯了会顺手复制还是要注意。第二MODELINGCOMMANDFLAGS_UNDO是让这次建模操作进入撤销栈的关键不加这个 flag用户事后就只能靠我的自定义回滚灵活性差很多。烘焙这一步本身也可能有耗时因为大量克隆体要真正生成网格对象。如果场景里本身用的是实例模式烘焙前的对象数量其实不大但烘焙后会显著增加。我的建议是烘焙前先确认一下克隆体数量级超过二三十万个的场景要提醒用户导出前再操作避免在视口交互阶段就撑爆内存。3.3 割草逻辑的完整实现烤完缓存就可以开始割草了。下面给出高度筛选和半径筛选两个最常用的实现。高度筛选适合把地面以上所有过高的“草丛尖儿”裁掉半径筛选适合清理某个障碍物周围的植被。def filter_by_height(clones, level, keep_lowTrue): 按高度筛选默认保留低于level的部分割掉高于level的部分 victims [] for obj in clones: if obj is None: continue y obj.GetMg().off.y if keep_low and y level: victims.append(obj) elif not keep_low and y level: victims.append(obj) return victims def filter_by_radius(clones, center, radius): 按到中心的距离筛选半径范围内的全部割掉 victims [] r2 radius * radius # 用平方距离避免反复开方 for obj in clones: if obj is None: continue diff obj.GetMg().off - center if diff.x * diff.x diff.y * diff.y diff.z * diff.z r2: victims.append(obj) return victims这里有个性能技巧判断距离时不直接开平方而是统一用距离的平方和半径的平方做比较。十万个对象看似只省一个Sqrt但乘在一起能明显缩短整段脚本的运行时间。我自己实测下来十万级对象能差出小半秒在这个处理量级上很可观了。使用的时候把筛选结果交给统一删除函数一次性放进撤销栈再批量删除def mow_objects(doc, victims): if not victims: return 0 doc.StartUndo() for obj in victims: if obj.GetDocument() is None: continue doc.AddUndo(c4d.UNDOTYPE_DELETE, obj) obj.Remove() doc.EndUndo() c4d.EventAdd() return len(victims)注意obj.GetDocument() is None这个判断。在实际使用中同一个缓存里可能出现嵌套对象父对象被删掉之后子对象会自动脱离文档如果不跳过它们后面Remove()调用就会收到无效对象引用轻则报错重则污染撤销栈。3.4 可回滚事件管理器的实现割草逻辑本身不难难的是回滚。我实现的RollbackSession是这样的class RollbackSession: def __init__(self, doc, labelmow): self.doc doc self.label label self.deleted [] def record_delete(self, obj): parent obj.GetParent() pred obj.GetPred() self.deleted.append({obj: obj, parent: parent, pred: pred}) def delete(self, obj): self.record_delete(obj) obj.Remove() def rollback(self): if not self.doc: return 0 count 0 # 反向恢复保证嵌套关系正确 for rec in reversed(self.deleted): obj rec[obj] pred rec[pred] parent rec[parent] try: if pred is not None and pred.GetDocument() self.doc: obj.InsertObject(pred) elif parent is not None: obj.InsertUnderLast(parent) else: self.doc.InsertObject(obj) count 1 except RuntimeError: pass self.deleted.clear() c4d.EventAdd() return count回滚时的关键一步是把对象重新挂回原来的层级。我优先检查pred删除时的前序兄弟对象是否还活着如果还活着就插回原位如果它已经被删了就退回父对象用InsertUnderLast挂到父级最后面。这个兜底逻辑保证了即使原位置上的前序对象也已经没了对象还是能回到一个合理的位置不会丢失。实际使用的时候回滚前我还建议把文档里刚发生的事件通知先停掉等对象全部恢复完再一次EventAdd()。原因是恢复过程中每个InsertObject都会触发视口刷新几十个对象还好几百上千个对象就会明显卡顿。用一次统一的刷新替代多次增量刷新是这类批量恢复的基本优化。4. 实测表现、踩坑记录与常见问题速查4.1 不同克隆数量级下的实测表现我在几个不同规模的场景里跑过这套工具把大概数据放在这里供参考。注意这些数据会随机器配置变化但相对趋势是稳定可靠的。克隆体数量烘焙耗时高度割草耗时删除回滚耗时2 万约 3 秒约 0.2 秒约 0.1 秒8 万约 9 秒约 0.8 秒约 0.4 秒15 万约 18 秒约 1.5 秒约 1 秒实际感知最明显的是删除耗时远低于筛选耗时。也就是说真正的性能瓶颈在遍历判断对象位置这个阶段不在 C4D 对象管理。这坚定了我在算法上优化的方向能用平方距离就不开方能用一次遍历就不分多次能在内存里做完的筛选就不要反复往文档层发事件。4.2 我踩过的几个大坑第一个坑是没烘焙就删缓存子对象。一开始我在没做 Make Editable 的情况下直接遍历缓存并删除结果删完下一秒 C4D 刷新克隆体全回来了。当时的心理状态可以说是崩溃的。后来才意识到克隆缓存是一个“生成的临时结果”它不掌握在用户手里你删掉的东西只属于那一帧的快照。解决方案就是烘焙前置尽量把“生成状态”变成“落地的可编辑对象”。第二个坑是SetDirty(c4d.DIRTYFLAGS_ALL)导致的连锁刷新。为了图省事我刷新缓存时全部标记结果整个文档里所有被污染的对象都跟着重建了一遍一个简单的参数调整变成了全场景重计算。后来我改成只对当前克隆对象做局部脏标记缩放到单对象粒度刷新成本立刻降下来了。第三个坑是循环里频繁调用c4d.EventAdd()。写第一个版本时我每删一个克隆体就通知一次 UI结果十多万对象删下来界面基本处于半冻结状态。后来改成先收集完所有要删的对象最后统一EventAdd()就再也没有卡死的问题。这个经验对所有批量操作都适用事件通知是给用户看的不是给每一个中间步骤看的。4.3 常见问题速查问题现象可能原因处理方式GetCache()返回None克隆体还没计算过可能在非主线程脚本里执行先调用一次c4d.DrawViews()或手动刷新视口再重新读取删除后克隆体又自动恢复没有执行烘焙删的是临时缓存操作前执行 Make Editable 并确认结果对象存在回滚后对象层级乱掉原位置的pred对象已被删除没做兜底判断改用父对象插入或记录更完整的对象路径信息脚本执行后半途卡死批量操作过程中反复EventAdd()改为收集完成后统一刷新一次EventAdd()结束删除无效对象引用崩溃父对象删除后子对象自动脱离文档删除前检查obj.GetDocument() is None这套速查表是我后续维护工具时自己最常用的索引。说实话每一条背后都是至少半小时的排查代价写进文档比重新踩一遍划算太多。5. 一点额外的使用建议最后再把两件实操里最有价值的小事说透。第一件烘焙和割草尽量做成两个按钮而不是一个按钮执行到底。因为烘焙本身就是一个耗时操作有时候用户只想把克隆体落地并不想立刻清理任何东西。分开之后用户可以分步骤决定结果也更容易定位问题发生在烘焙阶段还是删除阶段。第二件给回滚事件写一个清晰的日志。我在RollbackSession里加了一个label参数配合一个简单的控制台输出执行一次割草就会打出“Mow: 删除 3261 个对象可回滚”。实际使用中这行日志帮我排查了无数次“为什么数量对不上”的问题因为筛选结果每次都能直接和场景里的实际变化对上。工具写到这里说到底就是三个能力能安全地操作克隆体缓存、能按规则批量割草、能在出问题时把锅甩给回滚事件。如果你也总被大量克隆体磨得没脾气建议先从最后那层回滚保护写起有了安全网动刀的手才敢放得开。
