porting c# plugins from beta to patches in gamma works fairly well so far…thankfully, my plugins aren’t too complicated, hehe…
I was just about to publish the first one, triangle, when I ran into an error I don’t know how to fix:
the code in my beta plugin looks like this:
// Do some smoothing.
if (FSmooth[meshID]) (new SimpleSmoother()).Smooth(mesh, FSmoothLimit[meshID]);
mesh is created before in the actual triangulation operation. SimpleSmoother and Smooth are from the external lib, the rest are good ol’ classic beta inputs.
As I have separated everything nicely into it’s own operations in gamma, I’m confident the order of operations mirrors my old code. Still I’m getting an Object reference not set to an instance of an object. error.
Here’s what the above line looks like in my patch, as it’s own operation:
I’m a bit clueless on how to debug this. I tried wrapping the smooth function into a Try region, which helps to not stop the app but the error remains.
I have checked the mesh and the SimpleSmoother object by attaching Visual Studio- they look fine as far as I can tell. So by now I’m thinking I might be missing something more obvious…how can I find out what’s wrong?
p.s.:
One difference in the gamma version is that almost the whole evaluate function in the beta plugin has been inside an if statement (basically an Apply), now I’m structuring my operations inside a Cache region instead. Other than that, it’s the “same” I believe…
have you stopped in the same frame you entered the if while observing the values?
for debugging purposes i’d insert a togedge between AND and if. output all inputs of the Smooth node and stop.
or pause right before execution of the if and step in.
also, could the mesh have some uninitialized properties / been created but not fully initialized? (e.g. zero polygons)
It’s my first time attaching gamma to VS, not sure how to influence it, since I can’t set breakpoints :) But, I’ve added the TogEdge, so when this is true I’m looking at the inputs of the Smooth function, and at first glance, they look fine. Mesh definitely has points, segments, etc.
SimpleSmoother shows some methods which cannot be called in this context, not sure if this is an issue?
as far as i can judge nothing looks like a null reference.
does the error still occur with the togedge?
could the error stem from a later frame? the screenshot you posted suggests one keep on smoothing the mesh. (if true for consecutive frames and the mesh is stored in a pad)
So. just to make sure I’m doing it right - the way I do this (I wouldn’t know any other way) is to attach VS and then produce the error, which then causes VS to break. That’s the screenshot from above, with TogEdge in between, yes. At this moment, the TogEdge is true according to VS, so this is in the first frame, right? With TogEdge the if region would only run 1 frame anyway, no?
not sure tbh. I have everything wrapped in a cache region, so the way I understand it is it runs in the first frame (when I activate smoothing), comes to a result and doesn’t run again (until inputs change again) - am I wrong here? When inputs do change, the mesh generally also changes. The SimpleSmoother would remain the same, that is true, when moved to Create as suggested by @bjoern, otherwise it would also get recreated, correct?
sounds fine. seeing your last screenshot i assumed that the null reference error did not occur with the togedge. that’s why i speculated about consecutive frames.
so looking at the screenshot again SimpleSmoother - __auto_1 is not null.
you said Mesh isn’t null either.
what’s Smoothing_Limit_3? and enum? probably also not null
do you see a callstack in VS which you could traverse upwards to see if anything inside the Smooth method is causing the error?
no worries, thanks for your time. I was hoping initially this would be something more obvious. I will go ahead and redo the whole plugin, see if I can find anything. If not, i’ll publish anyway and might be back here :) thank you!
Try disabling “Just my code” in the VS debugger options. It should (assuming you use a recent version) decompile the code where it crashed and break there.
I have in the meantime repatched the plugin, with a little bit of refactoring, ie introducing more custom types, less copying my old code 1:1, and smoothing just works now.
Idk…I think I’m still doing pretty much the same thing as before…it works and I take it :)
