When will the Cookie SOP get some love? I haven't been around since before h12, but since then it has been quite broken. When it works, it works. But when it doesn't, which is more often than not, it just creates a mess.

I guess a VDB solution is fine sometimes for boleans, but when you need to keep the original geometry then what do you do?

It looks like it's been as broken since 2007 or earlier. Alas, so broken…

FWIW, I have been able to get this node be a bit more reliable by trying to ensure that input meshes were watertight clean polygons, as supposed to sending in a big mess of polygons (which I generally do with my network before reaching the cookie). But yeah this node could use some love..!

volume break is not bad either if you want to keep the input geos. Just use volume break to “break” the two inputs, then fuse them together

hope it helps!

I wonder if the new Solidify SOP in H14 (and possibly followed by a Remesh) can help condition meshes better for these type of operations.

The problem is that it doesn't even work on watertight, manifold geometry. If it did, that'd be a big plus, but I hit a case a few days ago where it went bonkers with a uniformly refined, triangulated cube versus a transformed version of the same cube. It thought a lot of the triangles from one cube were wholly inside the other cube, even though none of their points were inside, and they didn't come close to intersecting the other cube in any other way, so there were a bunch of triangles running out into the middle of nowhere.

Skybar
When will the Cookie SOP get some love? I haven't been around since before h12, but since then it has been quite broken. When it works, it works. But when it doesn't, which is more often than not, it just creates a mess.

I guess a VDB solution is fine sometimes for boleans, but when you need to keep the original geometry then what do you do?

Game graphics tend to get the worst end of the stick, as they not only need to retain the original UVs, but also tend towards the lower end of the mesh resolution spectrum, which makes cookie operations even more likely to break up.

VDB is useful sometimes (and actually I do use it a lot), but unless you're using pretty high settings it can be difficult to get clean, matching geometry output… and that's only half the story as you need to get it back to a poly object.

Convertvdb adaptive reduction can get reasonable results, but it's nowhere near as good as Polyreduce - which you'd have to be crazy to use on a naked VDB mesh. Combined adaptive and Polyreduce gets results, but it's dicey depending on the geometry.

So yep, totally agree: Cookie needs some love.

Polyreduce could do with some love too. I'd be interested in why it's so slow compared to other applications - it can be fatal if you accidentally drop it in a network with millions of input prims .. Esc to cancel doesn't work, regardless of what the tooltip bar says. Remesh can gotcha with that too.

AdamT
Polyreduce could do with some love too. … Esc to cancel doesn't work, regardless of what the tooltip bar says. Remesh can gotcha with that too.

Please file bugs for those! [sidefx.com] It's usually quite easy to fix issues where SOPs aren't interruptible. Sometimes it's not, and there are a few mystery cases I've hit, but those cases are relatively rare.

It's best if you can provide an example with the bug reports too, because sometimes it'll be stuck in some codepath that the developer didn't expect to take very long at all, but is actually taking ages. Sending in an example also helps people better understand the types of cases people want the code to be optimized for.

As a gamedeveloper using Houdini I would just like to put in my +1 for PolyReduce love, and +1 for cookie love

You'll be glad to know that about 80% of the time in PolyReduce on a 500x1000 triangle torus (1M tris) was being spent repeatedly traversing a linked list of maybe 3000 items to find the end maybe 3 million times. That part can be reduced to effectively nothing by using an array instead of a linked list. I'm going to go out on a not-very-long limb and guess that other meshes will exhibit the same unnecessary 5x slowdown. I've also put better interruptibility in, but I'll wait until tomorrow to see if my changes break anything before putting it in the public daily builds for Saturday.

Moral of the story: don't use linked lists unless it's absolutely necessary, and it's almost never necessary. :wink:

ndickson
You'll be glad to know that about 80% of the time in PolyReduce on a 500x1000 triangle torus (1M tris) was being spent repeatedly traversing a linked list of maybe 3000 items to find the end maybe 3 million times. That part can be reduced to effectively nothing by using an array instead of a linked list. I'm going to go out on a not-very-long limb and guess that other meshes will exhibit the same unnecessary 5x slowdown. I've also put better interruptibility in, but I'll wait until tomorrow to see if my changes break anything before putting it in the public daily builds for Saturday.

Moral of the story: don't use linked lists unless it's absolutely necessary, and it's almost never necessary. :wink:

I look forward to the day you will make VEX up to par with HDK in performance

pusat
I look forward to the day you will make VEX up to par with HDK in performance

Well, it is, for things that it can parallelize decently, and for those cases, it's certainly much easier to get that fast in VEX than in C++, so that's its huge advantage. For implementing messy topology manipulation operations, like PolyReduce, it may be a while, but I wouldn't be surprised if people could come up with clever new ways to do it using what VEX currently provides that are faster than the current PolyReduce. Most complicated SOPs have very old implementations that were optimized for different hardware or not optimized at all, because people try not to risk breaking them; VEX does at least an okay job of fitting new hardware, (though I'm hoping for AVX-256 and AVX-512 support in the future).

ndickson
You'll be glad to know that about 80% of the time in PolyReduce on a 500x1000 triangle torus (1M tris) was being spent repeatedly traversing a linked list of maybe 3000 items to find the end maybe 3 million times. That part can be reduced to effectively nothing by using an array instead of a linked list. I'm going to go out on a not-very-long limb and guess that other meshes will exhibit the same unnecessary 5x slowdown. I've also put better interruptibility in, but I'll wait until tomorrow to see if my changes break anything before putting it in the public daily builds for Saturday.

Moral of the story: don't use linked lists unless it's absolutely necessary, and it's almost never necessary. :wink:

That sounds awesome, I can't wait to give it a run

I'll file fresh cases of this cropping up if it continues. The Esc issue has been there for years, I've just gotten used to it as a fact of life with my older, slower PCs.

Neil, you are a star.

I've done a few real world tests, as a nicely formed torus is bit easy.

3% Polyreduce from a fairly complex 2.5m poly VDB of a canyon.

Previously: 10 mins 35 seconds
Now: 46 seconds

x13 speed increase!

Simpler geo gives smaller returns, a 463k poly ray cast grid down to 5s from 15s, which is terrific in itself, but obviously it's the big, dirty geometry that needed the TLC. Amazing.

Now I'm wondering how faster it might be if it used more than 3% CPU…(yeah pushing my luck perhaps )

Another day perhaps…thank you for this, you made my life a lot easier

(And timer & Esc now work perfectly!)

Havent tried it myself yet but those results AdamT is getting sounds amazing. Great work Neil !
You should do one of these fixes every week, fixing old cranky nodes and force them into 2015

AdamT
x13 speed increase!

Score!

Simpler geo gives smaller returns

That makes sense. It was an n^2 issue, so it'd have been worse for larger geometry.

Now I'm wondering how faster it might be if it used more than 3% CPU…(yeah pushing my luck perhaps )

Well… I could give it another quick profile and see what's taking up time. There were a few loops that looked like they'd be easy to parallelize, but they may not have been taking up much time. The actual reduction part probably isn't parallelizable, though. It'd be helpful if you could submit an example geometry file and either a HIP file or a description of the PolyReduce settings, since that could affect what takes time.

(And timer & Esc now work perfectly!)

Good to hear.

MagnusL3D
You should do one of these fixes every week, fixing old cranky nodes and force them into 2015

I got lucky with this one, but there's undoubtedly more low hanging fruit around. PLEASE, though, submit bugs/RFEs for things you want fixed or improved, ideally with example files, because it's very difficult to have a good sense of what's going wrong in practical settings without feedback and a way to investigate. You'd probably be amazed how few SOP performance RFEs we get; I can't remember the last one that wasn't submitted by pusat; (thanks, pusat!). Hopefully at least once we have more of the anonymous usage stats coming in, we'll have a bit better idea of what nodes people are putting down, but that doesn't give us much information to figure out what the pain points are.

Well I usually just mail support but perhaps I should start using the bug/RFE more?

So wishing the Dissolve SOP issue I logged (with example file and all) was looked at

And on a side not regarding reporting bugs, I dont think it would hurt to perhaps somehow make the bug/rfe page a bit more visible, and perhaps have some dedicated RFE options (and im sorry if they are there and I missed them).

Edit: And one more side not, the support team you guys have is beyond amazing.

MagnusL3D
Well I usually just mail support but perhaps I should start using the bug/RFE more?

They'll create a bug/RFE/question in the bug database from your submissions when it's something that needs a developer to deal with it. They usually try to reproduce things first, make sure that the relevant files are included. I suspect that the bug/RFE submission page actually just sends an email to support, but it helps make sure some of the relevant information is included.

So wishing the Dissolve SOP issue I logged (with example file and all) was looked at

Cool. I can't guarantee anything, but I'll have a look at it once it's in the bug database.

I dont think it would hurt to perhaps somehow make the bug/rfe page a bit more visible

Agreed.

perhaps have some dedicated RFE options

What sort of options?

the support team you guys have is beyond amazing.

Indeed! They deal with an amazing volume of stuff that never ends up having to go to a developer, thankfully! I'm certainly glad that we don't have to experience the tons of licensing issues they face.

ndickson
You'd probably be amazed how few SOP performance RFEs we get; I can't remember the last one that wasn't submitted by pusat; (thanks, pusat!).

Here I was worrying every time I submit one of those bugs, I upset a SESI developer

MagnusL3D
And on a side not regarding reporting bugs, I dont think it would hurt to perhaps somehow make the bug/rfe page a bit more visible

I use this link:
http://tiny.cc/hou [tiny.cc]

This has been mentioned a couple times but an RFE user voice would be really nice like the one Autodesk, Microsoft uses:
http://3dsmaxfeedback.autodesk.com/forums/80695-general-feature-requests [3dsmaxfeedback.autodesk.com]

IMO visibility is very important.

Well the Dissolve SOP issue I filed several weeks ago so hopefully it is already in your database, but to be on the safe side I attached it and put it in the bug/RGE page aswell

Regarding RFE options. I mean, like a master dropdown with bug/RFE as the two options. So it is clear that you are submitting a RFE.

And perhaps rename RFE to Feature Request because everyone might not know what RFE means. Specialy new people with lots of new viewpoints and ideas.