BoardCAD 2.x and 3.0 roadmap

Welcome to BoardCAD forums Software BoardCAD developers BoardCAD 2.x and 3.0 roadmap

Viewing 15 posts - 46 through 60 (of 63 total)
  • Author
    Posts
  • #4222

    surfineurope
    Participant

    @soulvoid wrote:

    Hi,

    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?

    #4223

    Anonymous

    Hi guys,

    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…

    #4224

    Anonymous

    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:
    org.boardcad.CADCore
    org.boardcad.BoardCAM
    org.boardcad.BoardCAD

    Or maybe it would be better like this:
    org.boardcad.Core.CAD
    org.boardcad.Core.CAM
    org.boardcad.BoardCAD

    Then we have the different packages which are specific to BoardCAD
    org.boardcad.BoardCAD.GUI
    org.boardcad.BoardCAD.Board
    org.boardcad.BoardCAD.IO(or loaders as java3d calls it… what about writers?)
    org.boardcad.BoardCAD.etc….

    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)
    org.boardcad.BoardCAD.GUI.android
    org.boardcad.BoardCAD.GUI.qt
    org.boardcad.BoardCAD.GUI.gwt

    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.

    #4225

    surfineurope
    Participant

    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

    /Jonas

    #4226

    Anonymous

    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.

    #4227

    surfineurope
    Participant

    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:

    org.boardcad.cam

    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:

    org.boardcad.gui.java3d
    org.boardcad.gui.jogl
    org.boardcad.gui.gwtgl

    Maybe we need something similar for wrapping swing or any alternative window toolkit. Not sure where we should put this though…

    /Jonas

    #4228

    Anonymous

    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?

    #4229

    Anonymous

    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.

    #4230

    surfineurope
    Participant

    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?

    /Jonas

    #4231

    Anonymous

    Hi,

    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
    http://today.java.net/pub/a/today/2006/02/21/building-guis-with-swixml.html
    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.

    #4232

    Anonymous

    Jonas/Haavard,

    Could you give me a hand with the command line args for compiling and packing the new class/package hierarchy in?

    thanks
    m.

    #4233

    surfineurope
    Participant

    @mocol wrote:

    Jonas/Haavard,

    Could you give me a hand with the command line args for compiling and packing the new class/package hierarchy in?

    thanks
    m.

    I’ve updated the instructions at:

    http://boardcad.org/index.php/BoardCAD:Community_Portal

    Actually it is starting to get a bit complicated so maybe we should start using ant (http://ant.apache.org/)..?

    /Jonas

    #4234

    surfineurope
    Participant

    @surfineurope wrote:

    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

    /Jonas

    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?

    /Jonas

    #4235

    surfineurope
    Participant

    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.

    /Jonas

    #4236

    Anonymous

    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

Viewing 15 posts - 46 through 60 (of 63 total)
  • You must be logged in to reply to this topic.