Havealot

@Keith Vick Maybe worth taking a look at the manual.

@Joseph Giuffrida You can export the cloner to FBX and reimport it. That should give you separate light objects with the animation baked into a track.

Shader Effector on the cloner or Shader Field in a Plain Effector should do the job, too. The UV information from the source mesh (plane in your example) should be transferred to the clones so they can be sampled correctly.

Why not attach a scene? That would help identify the problem.

Intersecting lines is not a basic computation (if it is meant to be robust). And if this is packaged into an Asset you won't ever see the interior nodes and wires unless you intentionally break it open. Stuff can be implemented in code or in nodes. So this is a bit like complaining about the number of lines of code in the source of C4D for a specific (seemingly basic) functionality. Take any basic operation in Houdini and start dissecting it. In many cases there is complexity several layers deep that builds the functionality of high level node. If you want to be overwhelmed by complexity, then try to understand all of it. If not, just use the high level node and enjoy it's functionality 🙂

Assuming I understood what you are after, this should be possible with Xpresso. Iterate over the clones, bring them into camera space and set the selection based on your criteria.

You can apply the Vertex Map tag to the SDS instead of on the input. That should work.

You could have used the script log for that long before an AI was able to deliver code that throws errors 😉

I assume it is mixing up different APIs. At first glance the errors you are getting are not related to the C4D version you are using to execute the scripts. Still impressive and I did like the hints it gave on optimizing for performance.

The MoGraph Cache Tag caches MoData (Matrix, Color, Weight,...). The Volume Builder is not a MoGraph generator.

@keppn I'd love to have generic presets, especially for different materials (leather, silk,...). But doing presets for simulation is really hard. Too many factors that have an impact on the outcome. You need very controlled conditions for presets to produce similar outcome. Mesh / Spline resolution for example dramatically affects the simulation. In your example both the shoe lace as well as the ring would have to be part of the preset to work reliably.

@Nicolas Straub The rigid body tag is part of the old bullet system and is not compatible with the new simulation system. To make your cloth objects more stiff you need to do the following: - Keep stretchiness and bendiness at 0 - Enable Soft Body and set the softness to 0 as well - Create a whole bunch of poles by increasing "Max Poles Per Point" and opening the spread. You want them all over the place and ideally some going diagonally through the object. In case of a ring you'll also want to set the shoot and hit side to "both". That will create additional poles connecting points across the hole of the ring. - Any softness you'll now still have means you don't have enough iterations to converge to the "correct" result - Another common workflow is to use a proxy geometry for the simulation. Lower resolution will converge more quickly (i.e. be less soft with fewer iterations). Once you are happy with the sim, use the mesh deformer to apply the simulation from your low res cage to the high res render mesh. - If it needs to be perfectly stiff, you can attach just a single quad polygon to the rope and cache it. Then you should be able to attach your shape to it through a constraint tag or through constructing a Matrix in Xpresso.

@Shrike: You should be able to send your feedback here. Bottom left, "Share Your Idea".

I got it now. I read your comment before looking at the scene. In context it does make sense.

Do you want soft body or rigid body? If it has to be rigid body, then go with Bullet. If you want soft body, you can make it less soft by doing the following: - Create more poles (Max Poles Per Point) - Increase the number of iterations. You can think of the iterations as passes in progressive rendering that will ultimately converge to the "correct" image. It will start crude with low counts and get closer towards the correct result the more iterations you do. Keep the iterations as low as possible and as high as needed to achieve the intended result. I didn't understand what you wanted to achieve with the target length of your poles set to 200%. If you are not planning to animate this, start with spheres of twice the size. Especially if you are trying to achieve a rigid look, you'll have to start with sizes that will fit into your collider in the first place. If you do plan to animate the target length, you should not keep in mind that you will produce conflicting constraints by setting the surface stretchiness to 0. If as sphere has twice the diameter (which would fulfill the 200% pole length requirement, then your edges on the surface have to increase in size as well because the circumference of your sphere is increasing. Either give the stretchiness a bit of room to let the poles do their thing, or scale the target length of the distance constraints on the surface accordingly. Some general remarks: - It's good for the simulation to have a) evenly sized polygons on object and b) evenly sized polygons across all objects. I low resolution collider is not going to work well when it is used with a high resolution simulation object. In your example, go with icosahedron as the type for your spheres as the gives you the most even distribution and size of polygons. - Adjust the Collision side if possible. When you have closed shapes (such as your spheres) use "Front" as collision side. That makes the collisions much more robust. If a point of one mesh manages to penetrate the surface the other (which is very hard to avoid), then it won't get stuck on the way out if you only consider one side of the polygons for collisions. - No need to make the cloner editable, unless you want the tags to have different settings @Cerbera: Why use static / moving mesh for large spheres? Ellipsoid should always be the superior collision shape in both quality and performance, no matter what the size is. Do you have an example where this is not the case? Hardballs4.c4d

@martijnP Here is a fixed version of the asset, that you can use until it is fixed in the data base. Just go to the Asset Browser, choose "Import Assets" from the Create menu, select the zip file (no need to unzip) and choose "Preferences" as your database (or any other db if you have created any). After that your scene file should load with the fixed version of the asset. If not, select the Greeble Assert in the Object Manager, go to the Basic tab and set the Asset Version to either "Latest" or the newest in the dropdown. Greeble_fix.zip

Try it with standard C4D modeling tools. It's the same. Select a polygon, store it as a selection, inset & check the selection again. All newly created polygons are not part of the selection.

@JohnDo All of this can be done as a linear sequence of modeling and selection operations without any branching. It can even be done exclusively with node capsules. I've attached an example of your setup done as a "modeling stack" and as a single Node Capsule with the parameters exposed. Both cases use Field to select the points to be chamfered. ScenesNodes_RD_0002.c4d

The simplest way to do this is probably to just add user data (int) to your "balloon controller master". Now make as many copies as you want, select your all "balloon controller master" and type rnd(123456;num) in the user data parameter. This will give you a random value between 0 and 123456 for each selected object. You can also iterate over hierarchies or lists of objects in Xpresso and use the index to vary the seed. It's a bit complicated though and I keep forgetting how it works and have to read the manual. So, if you want to do that, read the help or wait for Srek to respond 😄

I wouldn't recommend it (because GPU is faster) but there IS a CPU mode.

@BlastercastG If you upload the scene we can take a look. Hard to tell without a sense of scale or any of the settings.

@FerLop If you want to bool splines, use the spline mask, not the boolean.

@Björn Ewers Your chain geometry intersects itself. The sweep is not producing clean geo. And a general hint: Use an n-side instead of a circle for sweeping. That gives you the most control over the resolution of the sweep mesh.

Quotes from the first source (I assume these are the parts that Fritz was talking about): "Some attribute settings, such as Stretch Resistance, may vary depending on the resolution of your input mesh. For example, if you use a high resolution mesh to create silk, a Stretch Resistance higher than the one listed maybe required to obtain the cloth’s properties" "You will most likely need to edit the Nucleus solver attributes to settings that best suit your simulation. For example, increasing Substeps and Max Collision Iterations from their default settings is usually required, particularly for fast moving nCloth or if the nCloth is a high resolution mesh." "Depending on the units used to model the input mesh of your nCloth object, you may also need to set the Nucleus solver Space Scale." All three quotes revolve around one of the problems we are discussing in this thread. There is no stiffness value that always gets you silk/leather/xyz like behavior. It will depend on resolution, solver settings and scale. The only way to solve this is to enforce real world scale and to take control over the resolution of the simulation mesh. I also watched the Houdini video and don't get what it is meant to illustrate. Pretty much all of it is doable in C4Ds simulation system. - Remesh Node -> Remesh Generator - UV project node -> Not needed, if your initial object has UVs, they will be preserved during remeshing - Group Node -> Selection (Tag) - VellumCloth -> Cloth Tag (even the preset nature of this is the same as in C4D. A cloth is a vellum constraint preset that will configure stretch and bend constraints. The cloth, balloon and soft body tags in c4d are actually the same tag with different configurations) - VellumSolver -> (default) Simulation Scene - VellumPostProcess -> Cloth Surface Generator - Point Attributes to drive simulation parameters -> Vertex Map The only problem I see, is that in C4D some pins / constraints are set through a button that will consider the selection. That doesn't work for generator outputs. such as the remesh. But you have workarounds for that. You can for example use a cloth object (with all points fixed) to procedurally pin your cloth to, using the connector tag. Another important difference is that Vertex Maps not on the constraints but on the points of the mesh. They will automatically be transferred to the constraints when you link the map, but the effect will be a bit more indirectly. In exchange for that you get to use it without even knowing what "primitives" (in the Houdini meaning) or "constraints" are. So, if there was anything in that video that I missed, please point it out.

@Sukh Singh Try using a cloner to generate your geometry on the particles and export that. That should work.