Hello, I'm doing some small experiment with creating geometry, in this case polylines, that traces an original polyline. I would like to add n number of polyline primitives on a primitive wrangle's input1 (so input0 is empty), and fetch position data from this/those primitive(s), and then re-create an approximation of them with completely new geometry. I want the primitives to come in on input1 so that I will not have to delete them before or after creating the "new version". What is the right approach to this? It seems that creating the geo in detail mode or, when letting the original geo in on input0 is easier to get to work, but I would like to run this kind of code over primitives, potentially large amounts of them, and as said I would like to not have to delete any incoming geo - hence input1 and input0 empty.

The current code I have does not work, so I must be missing something. I have attached a hip file to this message so you can see the mini-setup with the code etc..

Hopefully someone can enlighten me

Cheers

Hi to run over prims, points or vertices you have to feed the first input(0), this will run over the element size, is mostly used to modify existing geo. To generate out of nothing run over detail/number of iterations. As I understand you did already(switching to the detail and replace @primnum with 0).

You can optimize a little by separating the process. A wrangle for the generation (detail) and a following one that runs over points to calculate and apply the position.

Seems a little faster than just running in detail(left), split(right).

Edit:
Here is a long term comparison, increasing segment length from 0.001 to 0.000002 (2.54 million points) in a frame rang of 0-120:

@vklc Thanks for your replies! Ok,so basically we cannot do any generation from scratch in points, prims, or vertex modes. To bad. I was hoping I could cheat the system and generate "per primitive" even if the input is not geoself(), but input1. Thanks for the comparison btw. Have you tried a comparison to see what would happen if you generate the primitives when the incoming ones are on input0 and you delete the original ones? So, in other words, how much does deleting geometry impact performance? I always hear that deleting geometry can become very expensive, but I'm not sure what that means in practice.

Thanks

Dougie0047
Ok,so basically we cannot do any generation from scratch in points, prims, or vertex modes.

You can (based on what you said in your original post that you don't want to delete the 'original').

Before you do your 'from scratch/based on existing points/prim operation' in a wrangle, name the originals prior to the wrangle as a group like 'group_preoperation' or something.

Then running over pts/prims as you desire, in the group parameter box of the wrangle put that group name 'group_preoperation'.

Then whatever new geo you create assign it a different group name like 'group_applied_operation'.

You now have the two sets which can easily be 'split' up independantly downstream of your choice and nothing has been deleted.

Dougie0047
Ok,so basically we cannot do any generation from scratch in points, prims, or vertex modes.

I depends how you see it, for simply reproducing geometry, like making a copy/copies with certain rules, then running over points/prims is way faster. Each element is an independent operation that runs parallel, meaning that each element do not know what the other do. It is like merging a few wrangles (for each element). This leads to imitation like comparing min/max values in run time.

But yes, to be precise to generate something from scratch a loop operation is needed. But still some optimization can be done. Like the example above. And as you see the most computing power is used for the generation – they same applies for deleting, maybe even more.

And if you want to optimize it even further, you could cache/freeze the line sop with different samples rates. For example cache 0 with 8 points, cache 1 with 16 and so on. And then use python to compare which cache file fits the current/needed point amount. Points out of range could simply removed by using the delete sop.

Dougie0047
Have you tried a comparison to see what would happen if you generate the primitives when the incoming ones are on input0 and you delete the original ones?

The problem is that the amount of points for the resampled curve will mostly never match the original one. You will end up using a loop operation anyway.

So if you really need a boost, try the cache approach or some sort of compile block setup (rarely used them).