[prototype] Doublecut (0.1.0a) - Need help debugging

thomthom · 12 May 2009, 18:06

Warning! Will cause Bugsplat!

This is made available for the sole purpose of tracking down bugsplats and working out general code structure!
It's intention is for other ruby developers to have a look at the code. If any curious minds want to play with the concept script, do so with the knowledge that it will crash SU at some point.

The Concept
This is a script which allows cutout components to cut out the opposite face of a parallel connected face.

Double Cut - Example.skp

Once you've done this, you can right click the component and enable the Double Cut.

The Inner Workings
The script works out which edges intersect the opposite connected face and generates a second cut-out component (double-cut) and places it in the model.
The double-cut component is locked and it's content is hidden in order to keep it out of the way from the users.
The script then keeps track of all cut-out components which are set as double cutting.
Double-cut functionality works on a Definition basis, not individual Instances.
If the original cut-out is modified the double-cut is regenerated.

The Problems
Keeping track of all the changes are not easy. A number of potentially useful observers has proven themself to be broken. Quite a few work around has been done to make this work.

What I'm tracking:

Placement of new double-cutting components
Copy+Paste
Paste in Place
Paste from another file / Import
Move+Copy / Rotate+Copy
Modification to the cutting geometry
Scaling - Does the component still intersect both faces to cut out etc.

At the moment I have these specific problems:

Bugsplat upon SU close (some times)
Bugsplat after creating a double-cut component. Then create a new model. (File->New). Then once again File->New; this causes a bugsplat.)
When a component is made unique I need to get hold of the instance of the new component definition and create a new double-cut for them. But the onEntityChange event and onComponentAdded event both triggers before the .instances of the new definition is populated.
When moving a component, a transformation to the matching double-cut is applied in the onEntityChange event which cancels all other observer events. Causing problems such as only one double-cut component being moved if multiple cut-outs are moved. Or interfering with Move+Copy leading to extra components placed in the model.)

From this thread, http://www.sketchucation.com/forums/scf/viewtopic.php?f=180&t=18964&p=155868, it seems that many of my problems are due to the fact that I modify the model from within observer events. So I wonder if I can instead of modifying within the events, push the modifications into a stack for later manipulation. But the question is; when is it safe to do so? And when/what will execute the changes? I want to avoid timers as I'm afraid something might slip past.

I'll be revising the whole working of my script. But I hope that some of the ruby scripters would have some time to have a look at my concept code and see if you get some ideas to tackle this challenge. (It's a long script, I know. Not necessarily the best to suddenly jump straight into. I have tried to make as many comments in my code as possible. But I'm sure there'll be lots of WTF when you read it. Still, I hope someone could have a look.)

v0.1.0 ALPHA! - WILL CAUSE BUGSPLAT!

Gaieus · 12 May 2009, 18:17

Hi Thom,

I understand that it's still kind of "alpha" now and mainly for developers to look into the code itself. Would there be any help - beside telling you that "yeah, indeed I get the bugsplat" if totally "lay" people jumped into testing?

You know I'm very curious and interested in this although I have always managed to "solve" the double cutting issue for myself (with the exact same, "opposite" component). So if I could be any help beside reporting bugsplats, let me know.

Chris Fullmer · 12 May 2009, 18:24

I'm in! I'll run it through the ringer when I get a chance. Unfortunately, I have never used observers. I sort of understand what they do, just not how they do it. But I'll give it a go!

Chris

thomthom · 12 May 2009, 18:27

At the moment, I won't have any need for bug reports as I might need to drastically change my code to avoid the bugsplat. So working on smaller bugs/quirks might not be worth the effort.

However, do feel free to test it out as a concept. See how it fits into your workflow in the large picture. See if it cuts when you expect it to cut etc. Just beware that it does crash. I recommend anyone testing it to disable it when they're not actively testing it.

thomthom · 12 May 2009, 18:28

@chris fullmer said:

I'm in! I'll run it through the ringer when I get a chance. Unfortunately, I have never used observers. I sort of understand what they do, just not how they do it. But I'll give it a go!

Chris

Thanks!

scottlininger · 12 May 2009, 19:38

Thom,

Fantastic idea!

One thing that might make your script simpler would be use a flattened copy of the window component to cut the 2nd hole instead of creating a new definition or group. (One less thing to keep track of and would keep the file size small.) However, I do like the idea of hiding all of the geometry inside the new hole to keep it out of the way... which wouldn't work with this approach.

thomthom · 12 May 2009, 19:44

@unknownuser said:

Fantastic idea!

Thanks.

@unknownuser said:

One thing that might make your script simpler would be use a flattened copy of the window component to cut the 2nd hole instead of creating a new definition or group. (One less thing to keep track of and would keep the file size small.) However, I do like the idea of hiding all of the geometry inside the new hole to keep it out of the way... which wouldn't work with this approach.

That assumes the cut-out to be symmetrical. I trace the intersections specifically since the opposite cut-out could very well be completely different.

thomthom · 12 May 2009, 20:15

Been thinkning of what Scott suggested in another thread; see if I can use use onTransactionCommit. I'll make a command stack, where I take all actions I currently perform in events and push them into the command stack array. Then I use the onTransactionCommit to execute them. Will see how that works out.

Chris Fullmer · 12 May 2009, 20:57

BTW, I'm really happy to see this script finally up and working. Even if it is a little buggy at this point. I know you've put a TON of time into it, so I'm glad you haven't hit any show stopper problems with the API or anything. Good work, keep it up!

Chris

thomthom · 12 May 2009, 21:03

I'd say the bugsplat is a show-stopper...

BillW · 13 May 2009, 08:31

Thom

I have had a component hole cutting tool for a while - it doesnt use observers as the original code is ancient.
Perhaps you might want to reuse.

A component placed on a face must have a set of linked edges which define the shape of the cutout which reside on the cutting plane of the component. This means that the geometry of say a window doesn't have to span the component cutting plane inorder to perform cut. Try it in the example file. Select all components and run "Component punch". Notice the circular window which shows the edges of the window outline seperate from the geometry.

If there is no back face (in the same mesh) parallel to the front face containing the component then the front face is cut only which allows the user to reuse for say running an intersection.

Punch hole in place of component

Example file

Regards

BillW

thomthom · 13 May 2009, 08:57

Thanks Bill for looking at this. I had a look at your plugin. The thing is that I want to make the holes editable, avoiding having to edit the holes separately. It's that process that takes time when I need to do revisions to model which I want to avoid.

plot-paris · 13 May 2009, 09:36

great plugin, Thom! this is one of the things that should have been a part of SketchUp all along. and now you did it!

of course its still alpha, but its such an important script. I felt like crying with joy when I first hit the double-cut command and all the component copies cut through the walls...

after playing a bit I found something interesting: the double-cut component only cuts through the second face of the wall, if it contains an edge in this second plane (example on the right). so if the component goes right through the wall and doesn't provide the edge in the second wall-face's plane, it doesn't work as a double-cut.
that means that you can only use a component for a wall with exactly the right thickness...
(did this last paragraph make any sense? quite difficult to describe... )

thomthom · 13 May 2009, 09:40

Try making sure you have edges where it intersects with the wall, then extrude further out once more. It doesn't detect faces intersecting the opposite face, but only edges.

thomthom · 13 May 2009, 09:46

Here's an example file.

0.1.0a

Gjenio · 13 May 2009, 09:52

I´m not a ruby expert therefore I cannot give you any suggestions, unfortunately.
But let me express my congratulation for your effort to develope such a plugin that will become one of the most useful sketchup plugins. Thanx!
Go ahead, please!

Sir · 13 May 2009, 10:09

this will indeed be an incredibly useful plugin! when doublecutting, will it make a permenant cut, or will it just make the intersecting faces hidden?

because this would then allow you to move the windows about, and as you moved them the wall would hide before them and then heal behind...

this will be so useful fo old skool windows where they didnt know what symmetry was

plot-paris · 13 May 2009, 10:21

@thomthom said:

Try making sure you have edges where it intersects with the wall, then extrude further out once more.

thats what I did with the example on the right hand side. so that means you always have to design Double-Cut-Components (DCCs as opposed to DCs (Dynamic Components) ) for a specific wall thickness.

now that I come to think of it, this may even be a positive thing - thus you will always see, if a wall is not exactly the right thickness

thomthom · 13 May 2009, 10:25

Mind you, if you make a DCC for a wall 200mm thick, and then try to place it on a wall 400mm thick; it won't cut initially. But if you scale the instance 2x in the components Z-axis so that it intersects it will make the cut.

thomthom · 23 May 2009, 11:39

I changed the script so all observers events where I added/removed/edited anything to the model where qued up in an command array. That array where then read by the onTransactionCommit. At first it appeared to work, but then I got the bugsplats again. (I might not have done the actions to trigger it initially.)

I've been trying to find the cause of the bugsplat, but all I've found so far is that it happens if I add/remove DDC after they have been made into DCC components. If I just move, rotate or scale them there is no bugsplat.

What I find very odd is that the bugsplat occurs when I open the second scene.


Make DCC
Add/Remove DCC (this will trigger the splat later)
File->New (New model opens, no bug splat.)
File->New (Blugsplat! Why so late?)

I'm wondering if it might be due to some entity references, but I reset all arrays/hashes containing references when a new model is opened.

The only thing I haven't tried is keep track of all observers and removing them. But I'm not sure if I'm able to remove them all...

Version 0.2.0a