Found 390 posts.
Search results Show results as topic list.
Technical Discussion » Strange behavior with edge transport
- jlait
- 6205 posts
- Offline
Total sets each point to the total of all *previous* points. It does not include itself. If I add back in the original relax attribute of each point after the transport, you will get the same result in both cases.
Technical Discussion » OpenCL CPU uses more ram?
- jlait
- 6205 posts
- Offline
OpenCL uses flat grids, while the native system uses tiled grids. This allows the native system to collapse constant tiles and use less memory. One of the big speed advantages OpenCL has on the CPU is due to the flat grids, however, so this is probably a trade off that will remain.
Technical Discussion » pcopen to add points based on distance
- jlait
- 6205 posts
- Offline
I strongly recommend using pcfind() instead. The pciterate loop is a bit odd, and pcimport doesn't help you with general attribute import problems, while the point() works everywhere.
Note the difference between len() and length().
// If closest point to us is farther than threshold,
// add point at midpoint
float threshold = 1;
int nearpts[] = pcfind(0, 'P', @P, /*maxdist*/1e20, /*numpt*/ 2);
// Nearest point is ourself, so we are interested in second
if (len(nearpts) > 1)
{
int pt = nearpts[1];
vector npos = point(0, 'P', pt);
if (length(@P - npos) > threshold)
{
// Too far, add a point.
vector midpoint = (npos + @P) / 2;
addpoint(geoself(), midpoint);
}
}
Note the difference between len() and length().
Technical Discussion » General FLIP Questions
- jlait
- 6205 posts
- Offline
catchyid
seems like squeezing too many particles in one voxel that should eventually spread up to maintain their particle separation
A subtle point about FLIP sims is that particles are just markers. They don't actually take any space themselves. This is why spawning particles inside a tank doesn't cause the water level to rise.
catchyid
My question: who defines liquid surface in the first place?
It is a chicken and egg question :>
The particles define the surface; then the surface is used to define the particles. In standard FLIP, each frame the surface is created fresh from the particles and isn't used on the successive frame. But during the frame's computation it is used for things like determining if particles are deep in the fluid or not.
Technical Discussion » Attribute wrangle significantly slower than the old point wrangle?
- jlait
- 6205 posts
- Offline
Lyubomir Popov
Just one more question - you mentioned holes in the point list left by the old scatter sop, how can I tell there are holes in the point list?
In geometry spreadsheet turn on “Map Offset” in the list of attributes. Scroll to the bottom and see if the last offset number matches your last point number. If it does, there are no holes.
I've linked the “Number count” to the number of points I have, and set “Thread Job Size” to number of points / available threads(8).
This is dangerous as you might run into the same situation as before with regard to thread balancing. If your operation is known to be really expensive, you can just use a fixed smaller number like 128, that way balancing across any number of points. (for example, if the last half of your geometry has very sparse points that aren't within interaction distance, you might be able to skip those faster)
Technical Discussion » Attribute wrangle significantly slower than the old point wrangle?
- jlait
- 6205 posts
- Offline
Thank you! This was a very interesting file. First, I'd propose a different piece of code:
since I don't like pciterate(). This runs faster in my tests, and I personally like the flow better.
The strange doubling of time is due to thread scheduling.
The old VOP SOP broke the incoming geometry into pages of points and ran on each page. The downside is if you have groups that have only a few points in a page, you are getting lots of overhead.
The new VOP SOP marshalls into 1k buffers and runs on those 1k buffers. This allows sparse groups to be merged together.
The downside of the merging, however, is if you have holes in your geometry. In this example the old scatter sop has left 8 holes in the point list. So the first thread will grab 1016 points from the first page and 8 points from the second page. This then locks the second page until the first thread is done. Normally this isn't noticeable as processing a page is very fast, but in a very expensive task like this it means that after all threads are done, one is stuck waiting for the first thread to complete. I didn't notice any difference on my 8-thread home machine, for example, as one has to wait for the second round to complete anyways; while my 12-thread linux machine has a big difference because we can complete the entire sequence in one burst vs two bursts.
If you use the new scatter sop you'll see the same performance, and slightly faster with my code. If you add a Sort SOP after the scatter, you'll force a defragment and close the holes and likewise get similar speed. I've added some notes to the bug to see if we can't get better heuristics to avoid locking a page like this. But this is all part of the eternal fight between grain-size and multithreading :> You have to chop up your work fine enough to things are balanced, but if you chop it too fine you die due to overhead. With VEX we have absolutely no idea how expensive your task will be. If doing really expensive stuff like this, you might be best using the By Number option to take control of the grain size and allow even finer grain threading.
int ptlist[] = pcfind(0, "P", @P, 9999, 9999);
vector pt;
vector t = { 0, 0, 0 };
int count = 0;
foreach (int ptidx; ptlist)
{
pt = point(0, "P", ptidx);
count += 1;
t += pt;
v@t = t;
v@pt = pt;
}
if(count > 0) {
@P += 100 * cos(@Frame) * t / float(count);
}
since I don't like pciterate(). This runs faster in my tests, and I personally like the flow better.
The strange doubling of time is due to thread scheduling.
The old VOP SOP broke the incoming geometry into pages of points and ran on each page. The downside is if you have groups that have only a few points in a page, you are getting lots of overhead.
The new VOP SOP marshalls into 1k buffers and runs on those 1k buffers. This allows sparse groups to be merged together.
The downside of the merging, however, is if you have holes in your geometry. In this example the old scatter sop has left 8 holes in the point list. So the first thread will grab 1016 points from the first page and 8 points from the second page. This then locks the second page until the first thread is done. Normally this isn't noticeable as processing a page is very fast, but in a very expensive task like this it means that after all threads are done, one is stuck waiting for the first thread to complete. I didn't notice any difference on my 8-thread home machine, for example, as one has to wait for the second round to complete anyways; while my 12-thread linux machine has a big difference because we can complete the entire sequence in one burst vs two bursts.
If you use the new scatter sop you'll see the same performance, and slightly faster with my code. If you add a Sort SOP after the scatter, you'll force a defragment and close the holes and likewise get similar speed. I've added some notes to the bug to see if we can't get better heuristics to avoid locking a page like this. But this is all part of the eternal fight between grain-size and multithreading :> You have to chop up your work fine enough to things are balanced, but if you chop it too fine you die due to overhead. With VEX we have absolutely no idea how expensive your task will be. If doing really expensive stuff like this, you might be best using the By Number option to take control of the grain size and allow even finer grain threading.
Technical Discussion » Bedrock
- jlait
- 6205 posts
- Offline
Bedrock lets you specify an incoming layer to be a reference height. This has two uses:
1) You can animate the incoming bedrock layer to create up-lift and other tectonic effects
2) You can adjust the hardness of the rock with depth using a ramp. This is relative to the bedrock height, letting you have strata that aren't flat.
1) You can animate the incoming bedrock layer to create up-lift and other tectonic effects
2) You can adjust the hardness of the rock with depth using a ramp. This is relative to the bedrock height, letting you have strata that aren't flat.
Technical Discussion » Convert HeightField not matching heightfield
- jlait
- 6205 posts
- Offline
Best to figure out the math with small numbers where the discrepancies are obvious.
If you have a 10x10 texture you want to fit in a 30x30 square, if you set the size to “30” you'll get a voxel size of 3. This seems obvious, but only is such because we store samples in the center.
If you do a height field convert you'll see it generate a 27x27 grid. This is because there are 10x10 points each 3 units apart, but due to the “fence-post problem” you have only 9 spans between points on each side, so only 27 total distance.
To get the points to be 30x30 you need a grid-spacing of
30 / 9
not
30 / 10
So you want to scale the size by (30 / 9) / (30 / 10)
Note the 30's cancel out, leaving 10/9 as the scale. Putting 10/9 in the uniform scale of the heighfield node will thus get the right result.
In the case of heightfield file, please note uniform scale *also* scales the y-axis, so you don't want to do that there. Multiply the size by the conversion factor.
So, in your case the ratio for 1024 is 1024/1023. Change the size to
100 * (1024 / 1023)
then do a heightfield convert. MMB the node and the points should give you a size of 100xYYx100
If you have a 10x10 texture you want to fit in a 30x30 square, if you set the size to “30” you'll get a voxel size of 3. This seems obvious, but only is such because we store samples in the center.
If you do a height field convert you'll see it generate a 27x27 grid. This is because there are 10x10 points each 3 units apart, but due to the “fence-post problem” you have only 9 spans between points on each side, so only 27 total distance.
To get the points to be 30x30 you need a grid-spacing of
30 / 9
not
30 / 10
So you want to scale the size by (30 / 9) / (30 / 10)
Note the 30's cancel out, leaving 10/9 as the scale. Putting 10/9 in the uniform scale of the heighfield node will thus get the right result.
In the case of heightfield file, please note uniform scale *also* scales the y-axis, so you don't want to do that there. Multiply the size by the conversion factor.
So, in your case the ratio for 1024 is 1024/1023. Change the size to
100 * (1024 / 1023)
then do a heightfield convert. MMB the node and the points should give you a size of 100xYYx100
Technical Discussion » Convert HeightField not matching heightfield
- jlait
- 6205 posts
- Offline
The convert height field, which generates the polygonal mesh, should be what gives the real location of your heightfield samples.
As such, if you import a displacement map you want placed on corners, not on centers, you will have to scale up the height field from file size by one voxel spacing. This will cause the GL visualization to go a bit far, but the convert heightfield should match. This also means the saved texture will have a correspondence that you expect.
As such, if you import a displacement map you want placed on corners, not on centers, you will have to scale up the height field from file size by one voxel spacing. This will cause the GL visualization to go a bit far, but the convert heightfield should match. This also means the saved texture will have a correspondence that you expect.
Technical Discussion » Convert HeightField not matching heightfield
- jlait
- 6205 posts
- Offline
Correct, sampling is on voxel centers. So the conversion places the points on voxel centers.
The displacement grid goes to voxel corners (but still displaces via centers)
The displacement grid goes to voxel corners (but still displaces via centers)
Technical Discussion » Compiled Block cause Error
- jlait
- 6205 posts
- Offline
Technical Discussion » Compiled Block cause Error
- jlait
- 6205 posts
- Offline
Thank you for the report. This does appear to be a bug with pcimport() running in a compiled system.
Bug: 84031.
Bug: 84031.
Technical Discussion » vex for $CY ?
- jlait
- 6205 posts
- Offline
Sorry, I read $CEY when you wrote $CY….
My usual approach is to use points to represent the copies. Then @ptnum is your $CY before the copy-to-points. If doing a for-each-point loop, I like to use an Enumerate to create an id attribute. Then point(-1, ‘id’, 0) can grab the currently processed point's id number, which acts like your $CY.
My usual approach is to use points to represent the copies. Then @ptnum is your $CY before the copy-to-points. If doing a for-each-point loop, I like to use an Enumerate to create an id attribute. Then point(-1, ‘id’, 0) can grab the currently processed point's id number, which acts like your $CY.
Technical Discussion » vex for $CY ?
- jlait
- 6205 posts
- Offline
Technical Discussion » Foreach Compiling Problem
- jlait
- 6205 posts
- Offline
This has also come up before…
https://www.sidefx.com/forum/topic/49364/ [www.sidefx.com]
Basically, if you have a dual socket system multithreading likely is running slower for you in 16.0. But the best option for simple examples like this is what Neil posted.
https://www.sidefx.com/forum/topic/49364/ [www.sidefx.com]
Basically, if you have a dual socket system multithreading likely is running slower for you in 16.0. But the best option for simple examples like this is what Neil posted.
Technical Discussion » point expression for vectors in pop wrangle
- jlait
- 6205 posts
- Offline
VEX overloads functions by return type. There are many point() functions that return float, vector2, vector, etc. Which one is called is determined by what fits best the return value.
@test will create a float by default as test isn't on the short-list of attributes of known types.
To force @test to be a vector, you can proto-type it with:
vector @test;
Or use the v prefix:
v@test = point(…);
When test is a vector, the vector version of point will be called, and you will get the x/y/z values.
@test will create a float by default as test isn't on the short-list of attributes of known types.
To force @test to be a vector, you can proto-type it with:
vector @test;
Or use the v prefix:
v@test = point(…);
When test is a vector, the vector version of point will be called, and you will get the x/y/z values.
Technical Discussion » Foreach Compiling Problem
- jlait
- 6205 posts
- Offline
In Houdini 16.0, the point(-1, ) function will lock unnecessarily. So if the total amount of work being done elsewhere is minimal, this lock can cause many cores to start to stumble over each other. On my 6-core, 12-thread machine I see the multithreaded running 2x faster than single-threaded. But perhaps you have more cores in your machine?
Technical Discussion » Vex point attribute issue.
- jlait
- 6205 posts
- Offline
I should clarify there is a fully predictable execution order. If you overwrite the same point with multiple setattrib() calls, they will overwrite in a predictable & consistent manner. (Specifically, later writes in the same elements kernel will overwrite earlier writes; and later elements will overwrite earlier elements)
This, however, is explicitly hidden during execution. point(0,) refers to the input, and there is no way to get the partially updated geometry.
Python does not have this issue as you have a handle to the actual live geometry in a python sop.
One approach I've seen done to do this in VEX is to build an array of all the newId for all the points so you can read & write to them in the array. Then when your algorithm is complete, write out the array to the points.
But ideally if you can write this as a ForAllPoints rather than a For Detail you can get more speed. Especially if your full use case is a forest of hairs rather than a single line - a single line will need O(npoints) passes so be pretty slow as a for-all-points or as a detail loop.
This, however, is explicitly hidden during execution. point(0,) refers to the input, and there is no way to get the partially updated geometry.
Python does not have this issue as you have a handle to the actual live geometry in a python sop.
One approach I've seen done to do this in VEX is to build an array of all the newId for all the points so you can read & write to them in the array. Then when your algorithm is complete, write out the array to the points.
But ideally if you can write this as a ForAllPoints rather than a For Detail you can get more speed. Especially if your full use case is a forest of hairs rather than a single line - a single line will need O(npoints) passes so be pretty slow as a for-all-points or as a detail loop.
Technical Discussion » Vex point attribute issue.
- jlait
- 6205 posts
- Offline
point(0, …) reads the value from the *input*.
It is impossible to read the current value from other points in VEX because while processing there is no guarantees about execution order.
Another way to look at this is to treat the setpointattrib() as all being applied *after* your shader completes.
It is impossible to read the current value from other points in VEX because while processing there is no guarantees about execution order.
Another way to look at this is to treat the setpointattrib() as all being applied *after* your shader completes.
Technical Discussion » OpenCL clCreateBuffer
- jlait
- 6205 posts
- Offline
No. You'll need to make a temp volume for this purpose. The clCreateBuffer() is done from the API layer, not from inside the kernel.
Since you are wrapping this in an HDA likely, you can always delete the volume when done. Empty constant volumes don't take any RAM so this should be difficulty in using it, not an optimization issue.
Since you are wrapping this in an HDA likely, you can always delete the volume when done. Empty constant volumes don't take any RAM so this should be difficulty in using it, not an optimization issue.
-
- Quick Links