search

LaserWeb / LaserWeb4

Collaborative effort on the next version of LaserWeb / CNCWeb
GNU Affero General Public License v3.0
704 stars 190 forks source link

"release" tasklist #191

Closed ghost closed 7 years ago

ghost commented 7 years ago

https://github.com/orgs/LaserWeb/projects/7?fullscreen=true

LW4 is still not 'released' - so wanted to see what remains to be done to get a minimally viable v.4.0.x out the door.

Then I took some of the harder tasks and moved them to a 4.1.x column (our exhausted dev's need a little break between 4.0.x release, and adding the feaatures marked for 4.1.x) #holiday

Basically - lets focus energy on getting 4.0 'released' (; before tackling new features

ghost commented 7 years ago

In other words

I see 4.0.x being

4.1 will be mostly

4.2 Will deal with adding some more graphical fixes like rotating/scaling/zoom

tbfleming commented 7 years ago

The code @jorgerobles is using as a reference doesn't work with threejs. @DarklyLabs was going to hire someone with a webgl background to take care of it, which seems like a good idea since their machine is the first to need it.

ghost commented 7 years ago

I understand yes, there are things we need lower level for. And three was way slower and more memory usage. Just saying (; easier. One pro, many cons hehe

So @DarklyLabs did you find someone to code that yet?

On Mar 5, 2017 5:25 PM, "Todd Fleming" notifications@github.com wrote:

The code @jorgerobles https://github.com/jorgerobles is using as a reference doesn't work with threejs. @DarklyLabs https://github.com/DarklyLabs was going to hire someone with a webgl background to take care of it, which seems like a good idea since their machine is the first to need it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/191#issuecomment-284235128, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2_ZV__y-NjCIdszuNVevJexBZge2ks5ritPLgaJpZM4MTcOx .

jorgerobles commented 7 years ago

Despite @tbfleming own right to do or not to, sincerely, I've been spending a lot of hours with webcam issue and fx. All the hard work is done. Indeed is done in regl. I estimate that won't be more than an hour to migrate to lwgl to any with enough knowledge.

El 5 mar. 2017 16:36, "Peter van der Walt" notifications@github.com escribió:

I understand yes, there are things we need lower level for. And three was way slower and more memory usage. Just saying (; easier. One pro, many cons hehe

So @DarklyLabs did you find someone to code that yet?

On Mar 5, 2017 5:25 PM, "Todd Fleming" notifications@github.com wrote:

The code @jorgerobles https://github.com/jorgerobles is using as a reference doesn't work with threejs. @DarklyLabs https://github.com/DarklyLabs was going to hire someone with a webgl background to take care of it, which seems like a good idea since their machine is the first to need it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/LaserWeb/LaserWeb4/issues/191#issuecomment-284235128 , or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2_ZV__y- NjCIdszuNVevJexBZge2ks5ritPLgaJpZM4MTcOx .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/191#issuecomment-284235895, or mute the thread https://github.com/notifications/unsubscribe-auth/ABoIYJ5t5qOCTdsTt325BA3C8msQ-MKZks5ritZkgaJpZM4MTcOx .

tbfleming commented 7 years ago

Here's a great intro to low-level WebGL development; I give this link to coworkers whenever they join one of my WebGL projects at work: https://www.youtube.com/watch?v=tgVLb6fOVVc

ghost commented 7 years ago

@tbfleming We have not found anyone with the skills and were relying on @jorgerobles to get us there. He has it most of the way and from what we can tell is at the point of needing to display his manipulations in the viewport. It would be very much appreciated if you could assist him with this so we can close it off. I know he has put in a great deal of time and pushed himself beyond his original knowledge and experience.

tbfleming commented 7 years ago

I thought I saw a screenshot of it in the viewport. I answer WebGL and LWGL questions as they come up, but they stopped coming up. The video I linked to should help him understand the shader code he's adapting and how to handle coordinate transforms.

ghost commented 7 years ago

It does display the camera in the viewport but without any of the manipulations. I am not sure where the roadblock is. @jorgerobles should be able to clarify.

jorgerobles commented 7 years ago

@tbfleming, certainly the last comment I post on https://github.com/LaserWeb/LaserWeb4/issues/139#issuecomment-281080867 was not a question. Was a problem I didn't know to resolve (https://github.com/LaserWeb/LaserWeb4/issues/139#issuecomment-281070061). Be aware that is very frustrating to do narrow questions for a thing I don't understand.

I have been clear that I don't know the technology. I realize have bitten more than I'm able too and even then I've been pushing me to keep it live. I've been composing code from here and there, figuring out to make it running on webgl.

In the meantime, I've mentioned you several times for assistance. I was just hoping you have the time to take a look a the code and guide me what is wrong.

That, and a lot of issues regarding a lot of code I've taken on my wing made stopping me to try further.

I was expecting that once made on regl could translate to lwgl, but first, lwgl was made by you, with your own focus and knowledge, rewriting REGL on a couple of nights as far as I remember. Only a developer with your wits could do that, and cannot expect me, that have not touch a line of webgl before understand the code you did. Documentation would be nice but I understand that if is only done to solve a problem for you have not the needing to document... Until someone need to extend your work with other feature.

I suppose I could be wrong, and you are not, that Three.js is framework slow and so so... If you know how to do the correct things. But at least is used by some hundreds/thousands guys that could assist if I dare, to do something I don't know.

I don't want to be negative. I'm exhaust trying to solve things out my reach.

jorgerobles commented 7 years ago

One last thought. We are on this. Coding for yourself on so high standard anyone could follow, is art but is not encouraging the rest of the crew to follow your steps. Indeed there's no much people in Laserweb dev team who dare to fiddle with the code you have done. This is constructive criticism, so peace :smile: Good night.

tbfleming commented 7 years ago

@jorgerobles I'm trying to point you in the right direction with that video link. Even if we were using threejs you'd have to port the regl code you found, which operates at a lower level that most threejs users deal with.

A reason I don't spend time on the camera stuff beyond answering questions is that I see it as a commercially-driven request, not a community-driven one. I only do commercially-driven requests when I'm paid for it.

ghost commented 7 years ago

@tbfleming Camera support was part of the very early Laserweb versions and was not considered commercially driven back then. This is a feature we would like included but is by no means specific to us. It would be good if you reconsidered your standing on this and helped @jorgerobles with his problems. As he mentions, you have set the framework for this part of LW and it is not easy for other developers on the community to jump in. He has also asked you very nicely on many occasions and continually putting him off like that is perhaps not a very good approach for a teamwork approach to this open-sourced project.

If it's all about the money, then please be aware that we have been financially sponsoring the developers on this project. When we last spoke about contributing to your time you made it very clear that you were not interested.

Please do not hold the project or features to ransom.

tbfleming commented 7 years ago

Camera support was part of the very early Laserweb versions and was not considered commercially driven back then

Wasn't this dropped by LW3?

continually putting him off

I'm not. I answer his questions. Something's wrong with the image before it even gets to the workspace, which means a problem in the shaders or the uniform or attribute values he passes to the shaders. He'd have these same problems if he tried to port the code he found to threejs.

When we last spoke about contributing to your time you made it very clear that you were not interested.

I said I wasn't interested in doing LW3 without being paid. I quoted my hourly rate to you.

Please do not hold the project or features to ransom.

I'm not. The camera transforms aren't built in to threejs and they're very low-level code. Even if LW4 was nowhere near ready for release you'd have this problem with LW3, which I didn't architect.

ghost commented 7 years ago

I guess @openhardwarecoza should make a decision on whether camera support is a commercial request or a desired feature in LW.

Once again I ask if you can help @jorgerobles compete the work he has already put a great deal of time into. If it's money that will make the difference then please advise the time you expect to help with this.

tbfleming commented 7 years ago

Depending on how far he got (I haven't looked at it in detail), 2-40 hours, with a minimum charge of 30 hours. If it's below the minimum, then I'll make the difference available for future requests from you.

Alternatively, I'll hook the camera up to the canvas pre-transform for free. He or someone else can insert the transforms.

jorgerobles commented 7 years ago

@tbfleming I did not embark on camera thing because was a commercial interest. I did, because I did get a blaze of blue laser on my eyes even with safety glasses and it's not nice. I appreciate that finally exposed your opinion about this issue. I prefer honest, direct answers rather than avoiding them. Fair enough, if you could fix the workspace video issue (weird offsetting) I mentioned will be great. I do understand your point of view that other thing than that (FX) is out of scope.

I said on #30 I'm out of this feature for a while. Hope all understand.

ghost commented 7 years ago

@tbfleming In an attempt to get closer to a 'release', have you had a chance to hook-up the camera to the canvas pre-transform as promised?

Can you elaborate on what is required to insert the transforms, as you mention?

tbfleming commented 7 years ago

1: not yet. I'll try to get it done this weekend; maybe earlier if I have time. 2: see my conversations with @jorgerobles across the issues.

tbfleming commented 7 years ago

It's hooked up.

ghost commented 7 years ago

Awesome! In bed already will run updated electron builds in the morning outaide of schedule too so we can test!

jorgerobles commented 7 years ago

@tbfleming, only stripped fxchain?

tbfleming commented 7 years ago

Yes. The bugs are in the transforms.

ghost commented 7 years ago

Thx Todd. Can't see the difference but I guess it's under the hood where the difference is.

There are memory overruns when the camera is selected after about a minute of LW running. Are these related to @jorgerobles work in the settings area?

tbfleming commented 7 years ago

The settings area still uses regl for webcam transforms. I hit memory issues when I used regl for the workspace, so it's a likely candidate.

ghost commented 7 years ago

Would it make sense to eliminate the camera view in the settings area and use the main viewport when setting the camera transformations up?

tbfleming commented 7 years ago

yes

ghost commented 7 years ago

From the hooking up work, have you had a chance to access the timing needed to complete the transformations etc?

tbfleming commented 7 years ago

I only looked at the non-transform stuff, but I think my estimate above is good if we stick with the current UI approach for camera calibration. There's a problem with that UI approach that @openhardwarecoza noticed; it's hard on users. Not everyone will be good at twiddling parameters until everything lines up properly. The best option for user experience is probably CV, but I expect that would take me ~300 - 600 hours to develop, which is probably not within budget. An alternative is for you to do the alignment before shipping and give each customer a config file specific to their laser.

There's also a problem that I haven't seen anyone mention. Camera alignment will be on a particular plane. Things closer to the camera will be smaller than they appear, and thus coordinates will be off.

ghost commented 7 years ago

You are right about the complexity of calibrating the camera. We will be supplying the calibration values within our machine profile, so our users do not need to touch this area.

I'm not sure I understand the problem with sizing you mention. The transforms both remove any lens barrel effects as well as distort the image to compensate for the plane the camera is on.

ghost commented 7 years ago

@jorgerobles added the small squares and circles to help with the final transformation. By placing a sheet of material on the base of the machine it's only a matter of aligning the square icons to the corner of the material, then move the round icons to the edges of the viewport to achieve the calibration. Only very fine tuning is necessary with the numerical values.

tbfleming commented 7 years ago

If you calibrate the camera for a sheet of paper sitting on the base, then the top of tall material will be off plane.

ghost commented 7 years ago

Ahh. ok. yes this is true. Its not a perfect system. The majority of customers work with thin materials. For tall materials they would align with another approach.

jorgerobles commented 7 years ago

@DarklyLabs, @tbfleming I was suspecting memory issues on REGL a while ago, but REGL was close to LWGL than any other approach.

@tbfleming Camera calibration was never meant to be a common parameter to be touched by users. I was expecting to go on a machine profile. Indeed, I did a standalone calibration app (now dropped) to get the values working, to paste onto the machine profile. Moving that UI to settings was short-sighted by myself 🙈 . The offplane issue was oversighted for me too :slightly_frowning_face:

@DarklyLabs, is the camera without effects on workspace useful for the end user? I realize it un-useful.

I was waiting to see if any other solution come along, but as not shown up and We want an stable release, We will move current code to his own branch and strip from dev-es6 (and master), to unblock this issue (#191). @openhardwarecoza what do you think?

Starting fresh, the only approach I have on mind is to make a floating window that could invoke over the workspace. KISS approach, no FX.

Further discussions around this should go on #30, again :smile:

ghost commented 7 years ago

@jorgerobles The camera is not useful without the transformations unfortunately. Rather than remove all the camera work from LW4, would it be possible to leave the camera selection and direct feed onto the workspace without transformations in place? Basically have the ability to select a camera (as is possible now) and have that fed directly to the workspace as Todd has just setup.

We can then work on the transformations in another branch and not lose the work we have struggled to get in place now.

cprezzi commented 7 years ago

I think, without the transformation, it doesn't make sense to underlay the video under the workspace. That would just confuse users. Instead, like @jorgerobles suggested, I would make a movable overlay box.

ghost commented 7 years ago

@cprezzi Users who are easily confused can just not use the camera feature and leave it disabled. @jorgerobles Can you explain what this moveable overlay box is?

cprezzi commented 7 years ago

@DarklyLabs I just mean I would not place a distorted camera image below the workspace, but instead show it in a floating window or sidebar. I think it's already a good value of just seeing what happens inside the machine while a job is running (like in OctoPrint or Repetier Server).

jorgerobles commented 7 years ago

Yes, like +cprezzi says that's the idea. I will do a mockup back at home

ghost commented 7 years ago

The purpose of the camera view is for material alignment and placement. Any camera will require some sort of distortion either because of its position or lens. Using it to just see what is happening in the workspace is a bit of a wasted portential.

ghost commented 7 years ago

Theres two distinct uses for Camera:

1: Safety: Camera inside enclosures, etc as well, not just top down views (4.0 release) 2: Material Alignment (Not in 4.0 - currently marked for 4.2 release according to the issues we need to solve first (outlined in https://github.com/orgs/LaserWeb/projects/7) 3.: (Wait I said two above?) - well, even when we get (2), we'll still need (1) - as LW is NOW and ALWAYS WILL BE a generic application. Whereas the Emblaser has a top down view, not all usedrs will. So (1) will stay anyway. It therefore makes sense to do (1) first, then (2)

For safety, floating view would be best - placing it behind the workspace, before it really really works, will just overwhelm us with users demanding it "work" without understanding how complicated the image correction filter stack + webgl actually is.

On Sat, Mar 18, 2017 at 1:25 PM, DarklyLabs notifications@github.com wrote:

The purpose of the camera view is for material alignment and placement. Any camera will require some sort of distortion either because of its position or lens. Using it to just see what is happening in the workspace is a bit of a wasted portential.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/191#issuecomment-287537624, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2zEkSSYhVPvpkd7cOUbRur67rZC5ks5rm78YgaJpZM4MTcOx .

ghost commented 7 years ago

As a sidenote, I can see @Darkly escalating the situation again. I still have this unposted draft from 2 weeks ago when the tensions got pushed beyond breaking point

The draft has been discussed out of thread with the developers:

I'm pasting it exactly as we all felt about two weeks ago, it was written right after https://github.com/LaserWeb/LaserWeb4/issues/191#issuecomment-284366460 and the comments that lead up to that and in the mean time some of the situations has changed, but I do have to address some of the issues. I dont have time at the moment to rewrite the draft, so consider the points accordingly.

[start quote from draft]

First off, I have no hard feelings about this, all round, against any of the parties involved. In fact, I take a lot of the blame for the state of this, on myself. Things started going a little offtrack around Oct last year when I realised the mess I am in with my job, and the ensuing 4 months of me making massive lifestyle changes and a new (awesome) job, and a tonne of stress. Only now that things are back to somewhat stable, do I get the time to get involved in this again. Maybe we couldve prevented some of the hard feelings if I did my job as founder better by managing the processes a little more actively

Theres nothing wrong with a little introspection, so allow me to backtrack over the last couple months. Here's a few of the "mistakes" we made that may help us right this all going forward

1) Donation / Sponsorship

As LW has always been a very informal sideline love for me, and when I was the only person working on it, the donations model worked fine.

But as we grew bigger I think this was the first major mistake we made.

In terms of a Community - it was (and still is) the most friendly format. But with commercial interests and actual professional developers, donations isnt a compatible model. I do pickup from @DarklyLabs's comment above that they feel upset that they "donated to the project" and now get pushed into a corner. I have also, in turn, from every single developer here, received expressed concerns over time spent on the features.

However as those were private donations, and never publicised, the other team members had no idea. I actually reached out to a couple developers yesterday, directly asking them whether Darkly has contributed at all (: (Only @jorgerobles responded by the way - which is fine, its their private donation, it is none of the rest of us's business...). The problem with this is, that, if not known, another developer may wonder "Why are we doing this at all". Myself included, sadly, didnt (still dont) know.

There is also a feeling among the team that the distribution is not fair. Some people got K40s. One of the developers (the one with arguably the most written lines of code - spread between many different repos, and even in branches we never got to use) has only made $50 so far!

To rectify this, going forward, we would really need to discuss forming a board where all the developers, together, can discuss whether a) a feature is community or commercial nature b) whether we want to do it as a commercial undertaking c) cost out and quote the vendor, d) split up the income proportionally to those doing the work e) task a project manager etc That would also avoid us getting in each other's throats. - sadly that starts to make my hobby sound like a job. I have no definite way forward here, and among the developers, we will need to take a long and hard discussion. This is way bigger than me. I can see that all those involved agree though, and that the discussion already begun.

2) Private Email communications This one lead to a lot of internal fighting among us developers. I went down Claudio's throat over nothing. Jorge felt Todd isnt helping him. Domenic feels people are holding him hostage. Meanwhile, there was a small book of history hidden into private communications, without which people get upset, sometimes without reason (looking at you Peter hehe) if the rest was known.

Even the simplest request or discussion needs to happen here on git, or on G+ for all to see - thats always been the rule. If something is really really private, i guess an email must suffice, but then at least CC the whole team.

Case in point - today was the first time I read (i may have missed a comment here or there but dont recall directly being involved in) that Darkly reached out to Todd, as an example. Conversely, Claudio and Jorge both reached out to me about the private emails from Darkly asking for features they feel, are too commercial in nature. (As I was not CCed I cannot say anything more about this) Domenic sent me an email this morning, I havent even opened yet. All of which serves just to vent, and not to resolve.

This also leaves me in a very difficult place to make any kind of call on old issues now (for example where i was asked in https://github.com/LaserWeb/LaserWeb4/issues/191#issuecomment-284275409 to "make a decision"), as I have only a percentage of the whole conversation

Rectifying this is (half) easy. Use GIT issues! Easy. the other half falls on the other side... If you feel pressured, feel like something needs to be paid work, etc, SAY it (example Todd, Sebastien. (; ) otherwise the other team members dont know why you dont want to help. In my case thats where Paranoia sets in (;

3) Pressure: We need to be very careful about placing deadlines / pressures / demands - as this is a project all of us work on if/when we can and when we feel like it. With pressures, the "feel like it" goes away. I might be guilty of telling Domenic we are "quite close" but even if it looks like that, things can go wrong and things take longer. That how software works. Thats even more so how open software works. Unless we go down the route in (1) above, this is an especially sensitive issue.

How to rectify this one? Well, for starters, the guys all need a break! I can see the burnout and I can see the tired. I worked like that for 7 years, I know the signs. Whether we have enough energy to finish the shortlist I added for 4.0.x release is unsure. I hope us talking about these issues helps recharge all involved just a little so we can get over the hump, then take a break (:

4) Generic approaches I stand by my developers on this one - cheap/free work will sadly have to apply to the whole spectrum of users. That is not new news. There are always clever workarounds that can be implemented in the existing framework, but the vendor may need to play with that themselves. Of course in terms of the wishlist of generic issues, a vendor's generic item might still be a lower priority than other items.

Appendix: I do want to extend my discussion to the Camera issue in particular. If we go by the argument of "what did lw1-3 have" - then yes, we should have basic webcam overlay in LW4. But LW1-3 all relied on the user placing the camera manually in the optimal bed center + height so that it lines up. If we look back at my first comment in https://github.com/LaserWeb/LaserWeb4/issues/30#issue-188552109, it clearly states "Desired result: Top down bed view to line up operations" - that comes from November last year...

We never had extensive optical correction filters. In terms of a community project, I would still say that suffices. sorry. The volume of work involved in proper WebGL development and all the maths involved in making all the filters work, combined with the skills needed to make it "easy" to configure (we are not there yet) - is after all a task that calls for a developer with a certain skill level above average. Its not a "add a button" or "can we extend the existing feature with one extra field" - its a monumental undertaking. (The work as far as it is now is already hundreds of hours I am sure) In particular because LW runs in the browser! The challenge is so involved that i cannot forsee any way that this would be possible without paying Todd to do it. Sure, eventually it would have an advantage for the community and other vendors, but there is a mechanical solution to this as a primary option. Note I did not come up with this opinion on my own. I think I speak for the entire team when I say this.

[end quote from draft]

Post note: Above I do mention overlay, but looking at the facts today (what we have, whats capable, webgl memory issues, and taking user demands into account, as well as keeping the generic approach) - i revert that stance in favour of a "webcam" window / overlay / sidebar instead of behind the grid.... FOR NOW. We can revisit nearer 4.2.x

On Sat, Mar 18, 2017 at 1:30 PM, Peter van der Walt (Gmail) < peter.plaaswerf@gmail.com> wrote:

Theres two distinct uses for Camera:

1: Safety: Camera inside enclosures, etc as well, not just top down views (4.0 release) 2: Material Alignment (Not in 4.0 - currently marked for 4.2 release according to the issues we need to solve first (outlined in https://github.com/orgs/LaserWeb/projects/7) 3.: (Wait I said two above?) - well, even when we get (2), we'll still need (1) - as LW is NOW and ALWAYS WILL BE a generic application. Whereas the Emblaser has a top down view, not all usedrs will. So (1) will stay anyway. It therefore makes sense to do (1) first, then (2)

For safety, floating view would be best - placing it behind the workspace, before it really really works, will just overwhelm us with users demanding it "work" without understanding how complicated the image correction filter stack + webgl actually is.

On Sat, Mar 18, 2017 at 1:25 PM, DarklyLabs notifications@github.com wrote:

The purpose of the camera view is for material alignment and placement. Any camera will require some sort of distortion either because of its position or lens. Using it to just see what is happening in the workspace is a bit of a wasted portential.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/191#issuecomment-287537624, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2zEkSSYhVPvpkd7cOUbRur67rZC5ks5rm78YgaJpZM4MTcOx .

ghost commented 7 years ago

Moving Filters/Transforms to #222 to be worked on when the time is ripe

ghost commented 7 years ago

We had a floating webcam window in LW1 https://plus.google.com/+PetervanderWalt/posts/BgL4uwYSL6t

webcam

And that worked just fine. Note in the webcam preview there, I had my webcam on the corner of a CNC machine

ghost commented 7 years ago

@openhardwarecoza Thanks for sharing your thoughts. Unfortunately Todd's cost for implemting this feature is far in excess of our budget, so it will have to wait until you and the team are motivated to implement it down the track. Just to set the record straight, our donations to LW developers have occurred after developers had done amazing work, not beforehand to try and receive special favours. As you suggest, we will refrain from this in the future and rely on you and your core team to judge the worthiness of feature requests and whether they constitute a commercial request.

I hope you can keep LW on track now that you are more settled. There are many core improvements needed to make the experience reliable for users before new features like the recent discussion on 3D printing, should be implemented (IMHO).

Good Luck.

ghost commented 7 years ago

Taking the 3DP example, contrary (:

At the moment @jorgerobles is at the end of his ability to implement webcam for example, but 3dp comes with a new team of people, who can actually help code too. Stimulating that, seperately and in parallel to other tasks, gives us the following: So him working on that if he feels like he wants to, then I say, please do!

1) Energy: New is always cool to work on. New always needs to plug into existing stuff. More often than not the energy from the new work, gets used to fix things on the existing side. (Almost every major revamp in LW's history stemmed from that. Examples: lw.comm-server is 100x better than my old server.js - that got born when we wanted to add TinyG even though I think we still have 0 tinyg users. The major performance boost we had between LW2-> LW3 on the gcode parser / 3d viewer was when we toyed with rotary axis ideas. Again, we dont have real rotary yet, but we do have the fixes of the work needed to play with rotary which was improved gcode parser and much lower memory usage in lw3, there are hundreds more examples) 2) Growth: Again, be careful of your needs vs all needs. You feel the focus is laser. Thats fine, but dont express it as "instead of something else" as someone may take offense at that. I say let everyone work on new ideas whether they make it in or not, doesnt matter.
3) Ideas: Read that 3D printing thread, look at how much talk that stimulated about making the UI "easier" which will (and already have) roll over into the CAM tab / laser / comms etc. Already, we removed CNC cam unless in CNC mode (making LW better for your users who dont have CNC)

ghost commented 7 years ago

@openhardwarecoza That's all well and good but you will need to manage your creation so it doesn't become a bag of half completed features.

ghost commented 7 years ago

Thats what https://github.com/orgs/LaserWeb/projects/ is....

On Sat, Mar 18, 2017 at 2:37 PM, DarklyLabs notifications@github.com wrote:

@openhardwarecoza https://github.com/openhardwarecoza That's all well and good but you will need to manage your creating so it doesn't become a bag of half completed features.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/191#issuecomment-287543301, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr22T5AefiUXuuXX0qJRAOK1HeEgXNks5rm9AGgaJpZM4MTcOx .

jorgerobles commented 7 years ago

Well, the plain camera approach is done, using a float resizable window. so @openhardwarecoza one less to go until release.

ghost commented 7 years ago

Awesome! Thanks!

On Mar 21, 2017 9:30 PM, "jorgerobles" notifications@github.com wrote:

Well, the plain camera approach is done, using a float resizable window. so @openhardwarecoza https://github.com/openhardwarecoza one less to go until release.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/191#issuecomment-288192468, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr21Y_8VrZwFgv78sMvPtlKhzuw-Cbks5roCVZgaJpZM4MTcOx .