Fritz

Redshift does not render signed distance field volumes as surfaces. Only float values as fog/density.
Here are the steps you need to do:
Put a volume material on the volume builder in fog mode.
Set the voxel falloff a bit higher in the volume builder for the object you want to render.
Go to the volume material and there is a slot for density or scatter. On the right from the presets (small arrow) choose volume builder. This sets the volume builder volume as the density of your volumetric effect.
 
Now it should show up. No RS volume object or VDB export necessary, but that would also be possible if you set up the density channel properly.

To spare you some pain, it was not only renamed. It works very differently now and the tutorial is unlikely to still be applicable. There is a legacy mode in the basic tab of the tag though if you really must follow the tutorial.
In general the new version works a lot better and there should be tutorials out there for that.

PForceObject node is what you are looking for. Pipe a P Pass group through it and link the force you want to use.

This is just not what it does. This "classic object" node is just import to the node setup. The scene root is the only output. What you are doing is setting the position to the same position on the imported copy. If you'd output that as a copy, you might see the result. For driving parameters the nodes cannot replace xpresso.

Pyro RS material is just a preset volume material and can't really be the reason. That is supposed to work, so if it doesn't it is a bug. To me it sounds like the VDB files are not transferred correctly. Another thing you could try is to "save with Assets" to a new location and try from there.

Make the extrude editable and check the surface orientations. Mystery solved.
 
Why does the extrude do that? Because it cannot guess intend. Each segment is processed individually and the surface orientation is based on some internal metric.

Something about the shader parameter is strange. It also doesn't habe the animation dot, but you can clearly animate it with xpresso. To workaround the missing entry, you can drag&drop the parameter onto the xpresso node from the attribute manager. Just drag the "Shader" text onto the nodes input or output area.

Vertex map has a "use fields" checkbox. After activating it you can use a shader field in the field list and link a texture. If you don't want any animation on the map or parametric evaluation you can then deactivate use fields again and the map stays as it was (just an optimization).

Hello Scifidesigner,
 
Volume workflows are very compute intensive (it's real 3D data that grows cubic instead of 2.5D surface data that grows quadratic) and a mobile CPU will be a painful experience with low voxel size. Most parts of the volume workflow scale very well with many CPU cores.
 
About your question:
The only way I know to bring everything together is alembic. Select the meshers you want to cache, right click, bake as alembic. An alembic object will show up that has the same geometry as the volume meshers. You can then deactivate and hide the original meshers. Since the effect has changing topology and likely a lot of it, just streaming the data from the alembic file can be a bit slow as well, bit should be fine. Depending on how you see it, an additional benefit might be the external alembic file, while the volume builder cache is part of the c4d file.

The Softbody simulation does not change the matrix of the object, but only the mesh itself. If you want to transfer that simulation, you'd need to use a mesh deformer that can transfer the low poly deformation to the high poly mesh.

Entries in the fieldslist are called "field layers". What you are cloning is the layer, that may or may not get it's effect and most setting from an external object or field. Remapping layers, for example do not. Field object layers do however. So if you clone the layer, it will still reference the same field object. You can duplicate the field in the OM and drag the new one on the cloned layer to replace the reference.
The main concept of field objects is the reuse of the same field in multiple lists.
This results of course in no clear assignment of a field object to a specific list and thus comes the field object layer concepts that reference a field.
 

Hi Happypolygon,
 
the two concepts are pretty similar, but have some differences.
SDFs (Signed Distance Fields) describe the distance to a mathematical surface. At any point in space you can check how far you are away to the closest point on that surface. The "Signed" in SDF just defines if this is inside of a surface or outside. This sign is what makes many boole operations and other effects easily possible by just combining these function for surfaces in a specific way and then you get a combined function that gives you again the signed distance to the combined surface.
 
SDFs in the volumebuilder do that, but discretize the distance in a volume (voxel). This has the biiiig advantage that you baked down the formula that supports everything. Finding the formula to represent an arbitrary mesh is very very hard and is doing babysteps with ML right now. With voxels you can just use a slow algorithm and bake it down to voxels. This of course then is just as precise as your voxels are smal. For infinite smal voxels, this becomes the correct SDF again.
 
You can render SDFs with many methods but the most common are raymarching and meshing with marching cubes. Raymarching you step through a pixel always half as far as the SDF tells you the closest surface is. Then you do that until you either left the scene in the back or you are super close to something and decide that you hit the 0.0 value of the SDF. Marching cubes is voxelizing the SDF and creating mesh patches where a voxel has corner values that are >0.0 and <0.0.
 
Metaballs are pretty much the same thing (math is a bit different and they don't describe distance to a surface but more a volume description of the surface), just that usually only spheres are used and the blobby effect which comes from combining the formulas differently. You usually don't do "Union" or "Subtract" but metaballs are added with their volume describing formula. That creates this volume preserving effect that SDFs don't have if you move them inside of each other. There is ways to have a bit of that effect in SDFs.
 
Rendering for Metaballs is pretty simular. Raytracing/marching or Marching Cubes.
 
Why does not everybody raymarch it ? Well... then you have the thing in your software. The viewport needs to support it. The renderer needs to support it, and there is pretty much no export to anywhere.
 
https://www.womp3d.com/
these guys are building an SDF modeler without meshing. Lets see how that goes.
 
Regards
Fritz

Documented and fixed 😉

If you have c4d 2023 the mix animation with the new simulation system should be what you are looking for. Just put a (new with jellyfish icon) softbody tag on the mesh turn on mix animation with force and set the force to something that still follows your animation enough but is not too strong to force through collisions. Also a collider tag on the doorframe (hanger icon).

Alt + G. Hide the parent group

Check the lower right of your screen in the Attribute manager. Die traffic lights control a setting in the object settings.

Run an optimize before the bevel. (U~O shortcut). There seems to be a duplicate point on the corner. Optimize welds them together.

import c4d from c4d import gui from c4d import utils def main(): doc = c4d.documents.GetActiveDocument() doc.StartUndo() #Don't know if this works like this at all selected = doc.GetActiveObjects(1) while len(selected) > 1: newBool = c4d.BaseObject(c4d.Oboole) doc.InsertObject(newBool) newBool[c4d.BOOLEOBJECT_SINGLE_OBJECT] = True newBool[c4d.BOOLEOBJECT_TYPE] = 0 doc.AddUndo(c4d.UNDOTYPE_NEW, newBool) tmpA = selected.pop(0) doc.AddUndo(c4d.UNDOTYPE_CHANGE, tmpA) tmpA.InsertUnder(newBool) tmpB = selected.pop(0) doc.AddUndo(c4d.UNDOTYPE_CHANGE, tmpB) tmpB.InsertUnder(newBool) settings = c4d.BaseContainer() res = utils.SendModelingCommand(command=c4d.MCOMMAND_MAKEEDITABLE, list=[newBool], mode=c4d.MODELINGCOMMANDMODE_ALL, bc=settings, doc=doc, flags=c4d.MODELINGCOMMANDFLAGS_NONE) if res and len(res) > 0: insertObject = None if res[0].IsInstanceOf(c4d.Onull) and res[0].GetDown() is not None: insertObject = res[0].GetDown() insertObject.Remove() doc.AddUndo(c4d.UNDOTYPE_NEW, insertObject) else: insertObject = res[0] doc.InsertObject(insertObject) doc.SetActiveObject(insertObject) insertObject.SetName(insertObject.GetName() + " Yay") selected.insert(0, insertObject) doc.EndUndo(); c4d.EventAdd() if __name__=='__main__': main()  
UNDOTYPE_CHANGE needs to be called before the change and the CallCommand started it's own undo. So I replaced it with a ModelingCommand that does the same. Also resolved the null node that happens (but not always), which requires an "undo new" for the child of the null if you take it out of the hierarchy. The modelingcommand adds an "undo new" for the null node it created, going nowhere because the null will not be added to the scene. The big difference is, the modeling command adds the undo step to the current undo scope that you started (all packed in one undo), but the CallCommand starts a new Undo scope. Cool script 😉
 
Regards
Fritz
 
p.s. plugincafe.maxon.net is a great place for getting help with the programming APIs. 🙂