kubaA quick experiment with rotating a cube suggests that the Fuse SOP does something similar to the Facet SOP with Consolidate Points Fast. I'm not sure what Consolidate Points Slow does differently, but it seems to also use something like an L1-norm, just with different results sometimes.
I wonder if the same thing happens in facetSOP?…
Found 830 posts.
Search results Show results as topic list.
Technical Discussion » fuse SOP distance
- neil_math_comp
- 1743 posts
- Offline
Houdini Lounge » Voronoi fracturing: Choseing the shape of the fractures
- neil_math_comp
- 1743 posts
- Offline
You should be able to get a Voronoi diagram of all hexagonal prisms if you want: just have a equilateral-triangular grid of points and the Voronoi diagram will be all regular hexagons. That said, you won't be able to get arbitrary shapes, unless there's some way to very elaborately mess around with how it measures distance. Alternatively, you could fracture it more finely and re-combine things, which might give more flexibility.
Technical Discussion » fuse SOP distance
- neil_math_comp
- 1743 posts
- Offline
It's because the fuse SOP uses the L1-norm distance (a.k.a. Manhattan distance) [en.wikipedia.org] instead of the usual L2-norm distance (a.k.a. Euclidean distance). The L1-norm is the sum of the absolute differences in x, y, and z; the L2-norm is the square root of the sum of the square differences in x, y, and z, so the L1 distance can be up to 73.2% longer than the L2 distance.
I don't know why it does this, but it does, and someone suggested that it shouldn't be an issue in any realistic case. I'm less certain of that, if only because it's so counterintuitive and uncommon in 3D graphics to use the L1-norm. It means that if you rotate a model, you can get completely different fusing behaviour because the L1-norm isn't rotation invariant.
I don't know why it does this, but it does, and someone suggested that it shouldn't be an issue in any realistic case. I'm less certain of that, if only because it's so counterintuitive and uncommon in 3D graphics to use the L1-norm. It means that if you rotate a model, you can get completely different fusing behaviour because the L1-norm isn't rotation invariant.
Technical Discussion » Houdini's Geometry Architecture
- neil_math_comp
- 1743 posts
- Offline
Fancier data structures are built when they're needed, e.g. in GQ (as the page Edward linked to describes), since most operations don't require them and they can take up a lot of memory.
Technical Discussion » while loop cooking forever
- neil_math_comp
- 1743 posts
- Offline
It may be useful to familiarize yourself with how a while loop generally works [en.wikipedia.org]. While loops will continue looping until either the condition value is 0 (false) or you explicitly break out of the loop. With a condition of 1 and no breaks, a while loop loops forever. Hopefully that clears things up!
Technical Discussion » Got my new compter but....
- neil_math_comp
- 1743 posts
- Offline
sami.tawilYes.
should the heat sink be stuck to the processor
do u have any advice to see if something is wrong?If there is no fan attached to the heat sink or if the heat sink is not thoroughly pressed to the CPU with thermal paste, that's a problem.
i just took off the heatsink…and there is some kind of meltes rubber on top of cpu and on the bottom of the heatsink..normal?That's probably thermal paste to help assist with thermal conduction from the CPU to the heat sink. Removing it might or might not have been a good idea, but make sure you stick it back on without removing the thermal paste, and press it on to make sure there's good thermal contact. Presumably there are also latches for the heat sink that you need to re-latch, and if you had to take the fan off the heat sink, it needs to be reattached.
If there wasn't a fan or other cooling system on the heat sink, that could explain the high temperature.
Hopefully everything's okay!
Technical Discussion » Building Octree: Octrees before rendering?
- neil_math_comp
- 1743 posts
- Offline
jason_iversenOnce I've cleaned up a few things, I may be working on that next, (unless I'm confusing it with something else). It sounds like it should be easier than parallelizing the k-D tree building in mantra, but I haven't looked at it myself.
Can we expect this work to accelerate building pointcloud KD-Trees and those Houdini operations that use KD-Trees too? (eg VolumeFromAttrib?)
WolfwoodndicksonKD-Tree stuff aside, these efforts are equally welcomed.
That one's kind of expected, since there's not much that can be done with just a few weeks work to reduce paging out to disk.
I hear ya. Paging to disk can bring a program to its knees. Reducing it usually involves a massive redesign/reorganization of how memory is used, as well as assumptions on how the program is commonly used, and sometimes even a complete change of how the program behaves.
Technical Discussion » Building Octree: Octrees before rendering?
- neil_math_comp
- 1743 posts
- Offline
KorhonIt's just the building of the geometry k-D tree structure used by mantra (presumably, that's most of what it's doing when it says “Building octree…”). This building was all serial before. Specifically, it:
Does this mean full threading of octree genetration? Or more threading? Hoping for the first!
- Builds a temporary k-D tree structure (that can be built in parallel), recursing in parallel
- Estimates the amount of memory used, recursing in serial, (fairly fast, so parallelization might not make a difference)
- Builds the usual k-D tree structure from the temporary structure, recursing in parallel
- Deletes the tempoary structure, recursing in parallel
- Reorders the bounding boxes pointed to by the k-D tree, in serial (because parallelization would get messy and might not help)
Of course, all bets are off if memory pages to disk, but when using 12 cores, building the temporary k-D structure seems to take 65-75% of the time and reordering the boxes takes maybe 20% of the time.
Technical Discussion » Building Octree: Octrees before rendering?
- neil_math_comp
- 1743 posts
- Offline
pbowmarI'll put Tim Horton's on speed dial. :wink:
Cool! Let's hope it's not Donut Day
Technical Discussion » Building Octree: Octrees before rendering?
- neil_math_comp
- 1743 posts
- Offline
Hi everyone!
I've just committed an attempt at parallelizing the construction of k-D trees (what's currently used in place of octrees), so I'd be really interested to see how it works for ya. Tomorrow's daily build should have the change, so long as that build works.
Caveats: For some renders, it temporarily uses a bit more memory. Also, on renders where the total amount of memory used approaches or exceeds the machine's physical memory, the performance may be as poor as before. That one's kind of expected, since there's not much that can be done with just a few weeks work to reduce paging out to disk.
I've just committed an attempt at parallelizing the construction of k-D trees (what's currently used in place of octrees), so I'd be really interested to see how it works for ya. Tomorrow's daily build should have the change, so long as that build works.
Caveats: For some renders, it temporarily uses a bit more memory. Also, on renders where the total amount of memory used approaches or exceeds the machine's physical memory, the performance may be as poor as before. That one's kind of expected, since there's not much that can be done with just a few weeks work to reduce paging out to disk.
-
- Quick Links