September 16, 2011 at 10:05 am #4222
Of course we could simply parameterise any surface with (s,t) and get normals, pointAt(x,y), etc. from this numerically. One risk with this is that we could end up re-implementing that code over and over again. One solution to that problem would be to write util functions like getPoint/NormalAt(x,y,CAMInterface). The problem with this approach is
that it may not give optimal performance as there might be implementation details internally which could be used to get a quick solutions but cannot be used from an external, generic function.
Just thinking out loud here, but how about having a common base class for the geometry models? This way we could implement the generic functions such as getNormal/PointAt(x,y) which use s,t that can be overridden where it makes sense. The functions you outlined makes sense to me and cover most of my use cases, the only thing I use besides them is a kind of normalised circumference so I can get toolpaths which are equal distance apart. Again, something could be made from s,t which would cover it, but I’d prefer to have it in the interface. I have no idea what to call such a function. There may be some similar function that may make sense f.ex. for calculating the surface area of the board.
If we have a separate geometry model from the board (which I would prefer), how do we connect the two?
I think the s,t parameterization must be on a surface level, since it may be difficult to use a single parameterization for a board that consists of several surfaces.
Methods like getPoint/getNormal could be placed on a higher level or common base class, like geometric_representation_item in step. I would like to implement getPoint/getNormal for any type of mesh so that we can import and cut boards from stl-files.
Maybe it would also be useful to have a more general function such as getPointAlongVector, especially for tool compensation of 4 and 5 axis cutting…
I don’t see a problem with connecting the board and the geometry model. The board could simply have a reference to the top level representation of the geometric model?September 29, 2011 at 12:07 pm #4223
just wanted to let you know I’ve started to put my stuff into the new packages to try and do a check in of the stuff I’ve done. I’ll do one checkin with the current structure, then start to reorganise.
One thing which is good (or annoying depending on how you look at it) with reorganising/refactoring like this is that errors in you design becomes very apparent. F.ex. The blank holding system contains code for generating 3d model for showing in the 3d view of the toolpaths and code for drawing the blank holding system in 2d. Very convenient, but correct design it’s not…
Bdw. Can we move this forum to somewhere else without any surfboards on the page so the forum is SFW? That would help me a bit…October 1, 2011 at 10:16 pm #4224
Had a look at the deployment diagram, if the CAM and CAD packages are supposed to be useful outside of boardcad, then we should have these as top level packages, right? so we have:
Or maybe it would be better like this:
Then we have the different packages which are specific to BoardCAD
org.boardcad.BoardCAD.IO(or loaders as java3d calls it… what about writers?)
Should we break the GUI up into platform specifics right away? ie.:
org.boardcad.BoardCAD.GUI.java(or whatnot to specify the standard java interface)
Is it likely that we want to divide up the cad and cam modules into submodules too? There may be GUI (like tool settings) and IO (g-code writer) which is natural to put into the CAM modules. Then the question arise, are there any GUI which can be used without BoardCAD that the cad and cam modules depend on? If so where do we put that, org.boardcad.Core.GUI?
Am I making any sense?
My idea here is to break it up as much as possible to force us to separate GUI and other components from each other, such that we do not get the issues I have now where f.ex. the machine holding system contain code both for drawing the system and generating the 3D model. Clearly this should have been separated into three different classes. I think this will be much easier to achieve if we have submodules like GUI as any GUI which is elsewhere will indicate that there is something wrong with the design.October 4, 2011 at 7:09 am #4225
My idea was to have each component in a separate package (possibly with prefix org.boardcad)
org.boardcad.gui: Contains scene graph and canvas, used by BoardCAD and BoardCAM
org.boardcad.BoardCAD: Contains frame and menus
org.boardcad.BoardCAM: Contains frame and menus
org.boardcad.board: all CAD-func specific for boards
org.boardcad.machine: machine specific code
org.boardcad.cadcore: geometery model
not sure where to put IO-stuff
/JonasOctober 4, 2011 at 10:42 am #4226
Ok, so everything that’s potentially common between apps and can be used outside of BoardCAD at the top level. However I was under the impression that you wanted to reuse parts of CAM outside of BoardCAD/CAM? If so where does this go? Are we going to put the 3d and 2d gui in the same gui bag?
I’d like to split things up even more as I said to subpackages so we get a bit better at separating GUI and other functionality, however I’m guessing this is a good starting point and we can organise and refactor as much as we can be bothered to in the future.October 4, 2011 at 12:27 pm #4227
We could add a GUI-less CAM-package that would be used by BoardCAM and easier to reuse. I would put it in a separate package:
With GUI I was mostly thinking about a platform independent way to define a scenegraph with pickable objects that reports back to BoardCAD/CAM when an object has been clicked or dragged. This could preferable be used both for the current 2D and 3D views. GUI should probably have wrappers for java3d, jogl, gwtgl that could be placed in subpackages:
Maybe we need something similar for wrapping swing or any alternative window toolkit. Not sure where we should put this though…
/JonasOctober 4, 2011 at 4:43 pm #4228
There are a few big ifs and but’s if we are to rewrite it to use only some gl binding for the rendering. gwtgl depend on the webgl standard which is as far as I know not a standard yet, if this is to run on android/iphone there are some issues with performance and we have to write code for drawing f.ex. beziers ourselves. It’s a bit of a rewrite, not a big problem but time consuming. And we still need additional gui on top of that. How do we organize the platform dependent code for f.ex. java, android and gwt?October 21, 2011 at 9:49 pm #4229
In case you haven’t noticed, I’ve done some refactoring, moving stuff into different packages, etc. I’ve used sub-packages, I think it’s a little clearer that way especially when it comes to figuring out which classes does what and are of which type. As I go along I’ve also tried to add setter and getters where needed, I don’t like having public variables which are accessed directly, especially if it’sin a completely different package. Let me know if I go too fast. There are probably some things that we may want to change which are in the wrong package and stuff like that. As I go along I write some notes on the
One thing that isn’t 100% clear to me, why are we doing this? Is the main goal to structure the project better so we can find where we can use the same interfaces instead of having duplicate code that does (more or less) the same thing? Is the goal to be able to support different platform like android and gwt? Is the goal to be able to make it possible to use as much as possible of our code base from outside of the boardcad app? If it’s all of the above, how do it prioritize? It matters for how we structure the code and what dependencies there are between packages.
On thing which may help us when it comes to supporting multiple platforms is the AbstractDraw class. It’s intended to make it possible to support printing and export to f.ex. pdf, dxf, g-code, etc. with only to have to re-implement the Draw class. Currently only JavaDraw is functional but in theory for drawing a board, measurements, knots, etc. this could be implemented using AndroidDraw f.ex. Still needs some GUI on top of that though.October 24, 2011 at 11:11 am #4230
Nice work Håvard! Just updated my svn and was impressed by the amount of work you’ve done. The structure looks fine to me.
For me the main goal with reorganizing the code is to make it cleaner and easier to understand, before releasing the scripting interface. This include removing duplicate code, create a better integration between bezier and nurbs functionality, and a single machine interface. I would like to be able to easily extend the functionality of BoardCAD through scripts, so that is my main reason for having a more general geometry model and a gui that can be accessed from outside the board component. Being able to reuse part of the code outside BoardCAD would be nice, but not my main priority at the moment. The same with other platforms, not something I plan at the moment, but would be nice to prepare for it. Having an AbstractDraw or drawing interface can be a good way to do this. These should use data types that are available on all platforms. Not sure which part of awt that are available on android and gwt?
/JonasNovember 9, 2011 at 12:11 pm #4231
AFAIK Android and Gwt have a set of GUI components and layouts similar to standard java, but they are in different packages and possibly have slightly different interfaces. Also Gwt lack canvas painting (drawing lines and curves) AFAIK, this comes through either SVG or HTML5 canvas plugin, both cases having their own issues I guess depending on browser…
I came across this
It seems very flexible and an easy way to abstract the GUI from the application. The thing is that Android and Gwt both have their own ways of declaring GUI in xml which seems to (nicely??) separate GUI from the core code. So using swixml we might be able to use the same pattern for the ‘normal’ java version. If we are really lucky we can develop the GUI without having to restart the app. I’m using a similar declarative technology called qml right now and it’s very easy and productive to change layout and add GUI elements and just reload the GUI without having to restart (and God forbid, recompile…) the app.
I still have a bit of cleanup to do in the main boardcad package, to separate it into sub modules and hopefully get some of the code into some submodule. It’s alot of changes, but that only goes to show how badly it’s designed (mostly by me I’ll gladly add…) as everything is interconnected. I have a couple of things I need to sort out, but I’ll continue on it shortly.November 27, 2011 at 9:42 am #4232
Could you give me a hand with the command line args for compiling and packing the new class/package hierarchy in?
m.December 4, 2011 at 6:58 pm #4233
Could you give me a hand with the command line args for compiling and packing the new class/package hierarchy in?
I’ve updated the instructions at:
Actually it is starting to get a bit complicated so maybe we should start using ant (http://ant.apache.org/)..?
/JonasDecember 6, 2011 at 6:46 pm #4234
For BoardCAD v2.x I think we can set a tentative date and decide on which bugs we need to fix and which features to include. We should release version 2.1 before the end of the year.
I’m planning to solve the following bugs:
3366734 – STEP compatibility
3366731 – Translate 3D does nothing with non integer
1806014 – 3D conversion is inaccurate
and implement the following functionality:
3165801 – Nurbs undo
3165807 – Create Bezier patches from curves
Shall we try to make a release before the end of the year? I had a look at the issues above and they are more or less under control. Not sure if the STEP compatibility is completely fixed yet, but it works fine in Rhino.
Is there anything more that we should add to this release?
/JonasDecember 9, 2011 at 10:27 am #4235
Yesterday I decided to throw away the old nurbs toolpath generation. It had gotten too complex as everything was done in the same code: 3-axis cutting, 4-axis cutting, sandwich compensation, perimeter stringers, and a lot of extra cuts that different machine owners had asked for. The shapebot.properties file was getting really big with lots of parameters that I couldn’t even remember what they did.
Instead the toolpath is now generated from a script so that it can be easily customized. The shapebot.properties file is still used to configure the machine, but has less properties. I also tried to make them a little more in line with what is used for the Bezier toolpath generation to make the integration a little bit easier.
Ideally we should have a single set of machine parameters that are used both for bezier and nurbs and it would be nice to be able to set them as in the bezier to gcode interface, but still being able to import and export them as a properties-file to make it easier to move them between different computers.
I the end I would also like to integrate the script toolpath generator using the abstract toolpath generator so we get a single machine interface, but I still can’t figure out how to use the bezier to gcode interface.
/JonasDecember 12, 2011 at 12:30 pm #4236
Ideally I’d like to have the possibility to save the machine settings to file, not just one file so you can have settings like “6-7′ sandwich board” or “9’+ balsa board” so all positions and speed are set when you load this config file. I think the java settings api or whatever it’s called have features for saving to file, if not we can easily write serialization to text
- You must be logged in to reply to this topic.