See: GU_RayIntersect::minimumPoint()

https://www.sidefx.com/docs/hdk/class_g_u___ray_intersect.html [www.sidefx.com]

PaoloGiandoso
When you say channel, do you mean a Keyframe? Is it the same thing?
Does creating a keyframe tells houdini to evaluate the text as an expression instead of a string?

Yes, that is what I mean. Once you set a keyframe, you can click on the parameter's label to switch between viewing the expression and what it evaluates to. I find this more useful than using backticks because the colour makes it easier to notice there is an expression and I can click on the label to see what value the expression produced.

PaoloGiandoso
Question
I wrote
`details(-1,"cutPoint")`
with backticks instead of
details(-1,"cutPoint")
why was that a mistake? Is not the attribute an expression?

I don't see any mistake there. You should be able to use backticks around the expression. I generally prefer creating a channel and writing an expression without the backticks because I find the change in colour makes it easier for me to easy notice what fields have expressions.

PaoloGiandoso
I saw that toward the end you used the function vertexprimindex(0, hedge_srcvertex(0, hEdgeToCut))
Is the primitive Vertex Index the half-edge number requested by the polySplit SOP?

The format expected by PolySplit doesn't use half-edge numbers. Imagine enumerating the edges of a polygon. It expects that number for your edge in the polygon. This is really the same number as if you enumerated the vertices in the polygon.

I think you want feedback instead merge for the loop's gather method. PolySplit was failing because it was asked to split at a non-existent location (edge #3 on a triangle). I've updated the code to determine the correct edge. It is also best not to assume a specific interpretation of the individual values in uv so the code now computes the position along the edge.

Attached is an updated example.

Inline points are identified with by a collinearity test with a tolerance. The "Collinearity Tolerance" parameter lets you specify much the angle can deviate from 180 degrees and still be treated as collinear. In your example, the angle formed from points 1, 7, 4 is close enough to 180 degrees (given the default collinearity tolerance) to be treated as collinear. The angle formed from points 4, 3, 0 deviates further from 180 degrees and is not treated as collinear. Decrease the "Collinearity Tolerance" parameter if you want to keep more of the points.

EMwavelength
your file throw warnings upon opening

The file was created with Houdini 19.5. Warnings about unrecognized parameters are not unexpected if using a file with an older version of Houdini. None of the warnings should impact the behaviour of the example.

You might be able to partition the geometry into chunks without reaching your system's memory limits. Making the chunks as small as a single primitive will likely introduce a lot of additional overhead. Consider larger chunks. The attached .hip file demonstrates a few ideas that might help you move closer to your goal.

litote
How do I mark the SOP that created the Packed Alembic primitives time dependent? Do you mean the Alembic node I used to reference the file?

Yes, I mean the Alembic SOP that created the Packed Alembic primitives. The Alembic SOP will automatically become time dependent if the referenced Alembic geometry is animated and the Frame parameter is set to $FF. You don't need to take any action yourself to mark it time dependent. All later nodes should automatically inherit a time dependency. The network editor can show you which nodes are time dependent with via a badge next to the node (see: https://www.sidefx.com/docs/houdini/network/badges.html).

Packed Alembic primitives reference a single frame of animation (see the "abcframe" intrinsic). For animated Alembic objects, the SOP that created the Packed Alembic primitives should be marked time dependent so Houdini will recook and update the "abcframe" intrinsic when you scrub the timebar. The RBD Packed Object DOP has an "Initial Object Type" parameter to specify how you want to handle any animation the referenced SOP geometry might have. See the description of the "Initial Object Type" parameter: https://www.sidefx.com/docs/houdini/nodes/dop/rbdpackedobject.html [www.sidefx.com]

hign
I really want to know
Why I rotate one axis, then the other, it works, except the 360 degree points
And ,how can I fix it(of course maketransform been learned)(for other scenario or example )
I think if I do not understand the reason, the same problem will happen again and again

The problem with your original code is how to handle situations when @newz and @mytan point in opposite directions. In these situations, dihedral() will return an arbitrary rotation that will map @newz onto @mytan but you want to further constrain it to a rotation that will keep the @N direction unchanged.

tamte
I'd prefer if those complications were eased
since we want to keep only transforms and preferably instancing

The current default is "Deform Geometry". This pretty much prevents the use of instancing.

"Merge With Parent Transform" sounds like the behaviour you are actually asking for. Its unfortunately confusing name probably hides the fact it is the mode you really want. Ideally, this should be made the default and the Alembic ROP should behave better when using "Merge With Parent Transform" without a "path" attribute.

Guy Micciche
What I did that got it working:
Create an Attribute Wrangle and make Run Over "Primitives".

Alembic archives have a structure similar to a filesystem. This structure is meaningful to many tools that process Alembic archives. Here are some good guidelines when using the Alembic ROP:

1) Explicitly tell the Alembic ROP where to place everything in the Alembic archive via "path" attribute. This should be a primitive string attribute.
2) Make sure each Alembic Shape node has a unique parent (for example, use paths for your shapes like "/piece0/piece0Shape", "/piece1/piece1Shape", "/piece2/piece2Shape"... instead of "/pieces/piece0", "/pieces/piece1", "/pieces/piece2").
3) Change the "Packed Transform" parameter to "Merge With Parent Transform" to avoid complication with packed primitives that will force the Alembic ROP to rename your nodes.

Take a look at the Group Find Path SOP. It can likely simplify this task. Attached is an example of a mode that may be helpful for this task.

The Alembic HOM Extensions provide access to the range of time samples in the Alembic archive. You can convert these to frame values if needed.

midorisalt
I have attached a test scene with showing the problem. There are two alembic outputs inside the geo node, and the only difference is that the copy to points node has "Pack and Instance" enabled in the right side tree.

Instancing is not being used in your example as the Alembic ROP is set to export deforming geometry. You can easily check if instancing is used with Packed Alembic primitives by inspecting the "abcsourcepath" intrinsic.

The structure of Alembic archives is significant. It is good practice to explicitly specify where you want everything to be placed in an Alembic archive. Attached is an updated example that uses instancing and structures the scene so each box has a separate Alembic transform node associated with it.

Alembic archives have a lot of overhead when using instancing. For such small objects like a box, the overhead will significantly outweigh any possible benefit.

Can you share an example Alembic archive and .hip file illustrating the problem? We have not been able to reproduce the described behaviour.

The Clean SOP has an option to remove unconnected points and should be removing them unless you turned off the option. If it is failing, would you be able to share a simplified example demonstrating it fail? An Attribute Wrangle SOP iterating over points with an expression like “i@unconnected = (@primnum < 0);” should be able to identify unconnected points. A future release of Houdini will make it a lot easier to identify unconnected points.

The Alembic library imposes some constraints on how data can be organized. The path attribute lets you tell the Alembic ROP where you want everything placed in the resulting Alembic archive. The warning message is telling you that some items could not be placed in the location you specified so the ROP has moved the items in order to export them to the Alembic archive. I suspect your “/op:/obj/geo4/bough_br” and “/op:/obj/geo4/branches” primitives are packed primitives containing geometry that cannot be exported as a single shape node in an Alembic archive. For example, if they contain polygons and unused points, the Alembic ROP will need to create a PolyMesh to hold the polygons and a PointMesh to hold the point cloud (they cannot both be called “/op:/obj/geo4/bough_br”). If it is not obvious which parts of the geometry have to be split into separate shape nodes, take a look at the “/op:/obj/geo4/bough_br” and “/op:/obj/geo4/bough_br_1” items from the resulting Alembic archive.

This bug was fixed in Houdini 18.0.307.

Houdini lazily loads Alembic data. It should only load data as needed from the Alembic archive. If you only look at a single frame of the data, it will not pull in the other 299 frames.