It's fast!

Published February 11, 2011
Advertisement
I haven't worked on the "project" too intensively (because I worked with it intensively) but I managed to optimize the thing, so it's lightning fast now. I optimized it by using two dimension array to store the file like I mentioned previously. I can do that, because the specifications say that the max linelength of the G-code is 256 (or less in case of older implementations, I found that 70 is the minimum). Maybe that means a lot of wasted memory, but the 10-20 times faster parsing is totally worth it.

I fixed lots of bugs (and left even more), reworked the state machine (the former was a joke: every edit feature had it's own state variable. Total crap), some refractoring. It's easier to polish a program, if you are actually working with it and it's not just some toy.

I added new and pretty useful features, such as:

  • Snap to point
  • Cycle between overlapping points for selection
  • Rotate selected with center point - reference point - new direction
  • Mirror selected Vertical/horizontal constrains work with these too
  • Set start/depart of selected sequence
  • Some special features for my need:
    • Display foam (the stuff the machine cuts)
    • Set foam position and size
    • Toggle tool-swept path: it would be easier to explain if I spoke English. So the hot wire melts the foam, and it melts in a much bigger diameter than the diameter of the wire. And that's a very important info for stable cutting, for designing trajectories for small surface features, etc
    • Windowing: I added dialogs for text/number imput. Such as setting feedrates, entering comment text etc. Message boxes.
    • Better file stuff: save/save as/open/new works pretty much like in other programs
    • Data type-in: If the user hits enter during certain commands, values can be typed into a dialog box instead of clicking with the mouse in the editor. Offset values for moving, angle for rotation, insertion coordinates, etc.
    • Feed system reworked. There are no default feeds, all feed values are loaded from the CNC file and the user can only assign those loaded values. However, the user can define new feed values and redefine existing ones (obviously, the data is updated accordingly). I found this system to be quite intuitive (much more intuitive than making all the feeds accessible and with some hard coded default values that totally fucked up the whole thing when loading the values form the CNC files on top of this "feed table". And better, if there weren't any pre-defined feeds and feedrates were just thrown around without control). The only flaw is that gradual feed changes cannot be used (or have to be edited manually)
    • Calculating total machine time
    • Progress bar...One very important thing is still missing: Undo/Redo. That will be the next big and unavoidable step.

      http://www.sendspace.com/file/lhsy8v

      Note, that the help text inside the program is OFF, the "manual" is the right thing.
0 likes 4 comments

Comments

unbird
[quote]It's fast![/quote]

It is :) Congrats.
February 12, 2011 01:19 PM
Aardvajk
I was looking at your site again the other day and it occurred to me - in addition to designing paper models, this [i]could[/i] also work as a [url="http://www.unwrap3d.com/u3d/index.aspx"]UV unwrapper[/url].

Apart from Blender, which requires a brain transplant and heavy use of prescription drugs to be able to use, I'm not aware of any free software that does this.

If I understand your software correctly, could this not also be used to unwrap a 3D model, generate a 2D plan of it for texturing in another application as well as working out the correct UV values for each vertex?

Just a thought. Probably a wider market for a decent UV unwrapper than a paper modeller, although I will also say that your paper tank was quite stunning in its detail. Not much use in an actual war though if the enemy had matches or a fire hose.
February 13, 2011 10:01 PM
szecs
Well, I'm surprised that there aren't any decent free software that does UV unwrapping. Maybe this program could be used for that too, but UV unwrapping is bit different. In the paper modeler, triangles always keep their exact size since paper cannot be stretched, while in an UV unwrapper, triangles can be skewed and distorted. That means the algorithm is different. Maybe not so different, I have to think about that.

Anyway, I will add texturing to the program later, but I think I will only work with ready made models: so texture mapping must be handled somewhere else and the program will only unfold the texture with the model, so it can be printed. Which isn't a big problem, because the model has to be made somewhere else anyway, and I don't plan to expand the program to a full modeler, that's way out of scope for me.
February 14, 2011 07:25 AM
Emmanuel Deloget
Well, you are basically working on a constrained-yet-simplified version of an UV unwrap algorithm, so in some conditions are here, you may be able to transform the algorithm to unwrap 3D models.

There are many UV unwrapping algorithms, some of them takes the mesh topology into account, some are aided by a designer (the user defines the cut line ; this simplify the work of the algorithm ; see [url="http://www.polygonal-design.fr/e_unfold/features.php"]Unfold3D[/url], which I find quite interesting ; implementing a similar algorithm should not be very difficult).
February 14, 2011 01:13 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement