Orientation axes are completely borked

The orientation axes are completely and utterly broken, and apparently were designed and implemented without any logic or testing whatsoever.

Q: Why would both the X and Z entry boxes rotate the part the exact same way!!!???
Q: Why would the numerical entries change inexplicably to other (often with 2 decimal places defined) random numbers after leaving the dialog and then coming back to it!!!???
Q: Why does a user have to wait while you calculate and display the graphic orientation with each number typed!!!???

A refresher for those who seem to be unfamiliar:
X, Y, and Z are the cartesian coordinates of the SPACE the parts are in, and are NOT some random coordinate system somehow kind of but not really attached to each part. Modifying any axis by an increment therefore must only rotate the selected object around THAT fixed in space axis and ONLY that axis.

Please fix this bug. I cannot understand at all how this got through your QA or is thought to be correct or acceptable behavior. This should be a priority fix, as it’s not just unbelievably stupid and embarassing for you, it’s incredibly frustrating for anyone trying to use this software.

Also, having it update the graphic when editing the text box is really inefficient, not at all best practice, and extremely annoying. If you feel the need to update when clicking arrows, fine, but do not update the graphics when the change occurs by editing the text until the user leaves the text box or hits enter!

Seriously, using this software makes one wonder if the people who wrote it have ever used any programs before - not just graphic programs. I am constantly puzzled by why I need to tell you this stuff. This is application programming / GUI usability 101 level stuff!

On a better note, my prints are coming out nicely, when I can finally get through the software and get the job to the printer…
Thank You.

They aren’t broken, they’re local object axes, not global axes.
They rotate with the object.

They do go into gimbal-lock and screw you entirely sometimes. Two axis will do the same motion and one doesn’t exist. It happened to me with the Egg file just an hour ago. The solution is delete the model and do different motions next time.

1 Like

@Ante_Vukorepa Why? They don’t work. They don’t make sense. What are the benefits? If they are local, and they actually worked, then you would have to remember whatever axes that object came in on. There is no logical reason for this. It’s unintuitive, adds no value, and it’s buggy!

@JoshK Bwaaa! That’s a solution? Yikes. I think you mean working around bugs.

I think the solution is to open source the code, and get more eyes on it to help iron out the bugs. That and implement python bindings to the API that has not been written yet but would be. That way I can write a blender addon and ditch this crappy Windows box forever… Formlabs sells a printer, and gives the software away (good thing) - there’s nothing in this software anyone wants to steal! There is however a lot of stuff that would likely get fixed and improved upon. Open it up, please. Or at least, opensource the protocol and format sent to the printer - that way people can implement their own front end to it and never have to use Preform again.

You’d probably sell a lot more printers if you did…

Well yea, work around.

It’s not a bug, it’s an implementation limitation. The math hurts my head, so I won’t try and explain it quantitatively. But as mentioned by JoshK, the term for this behavior is indeed “gimbal lock” and it’s a basic consequence of rotating an object in 3D. Ante’s explanation is also correct, the behavior occurs because the object’s pitch/bank/yaw are defined locally with respect to the object itself. Technically, you only need two axes to orient an object arbitrarily in 3 dimensions. Yaw and Pitch alone cover all possible pointing “vectors”. The third axis is actually redundant, and when it aligns in certain ways, it “appears” to effect one or the other axes as you’ve observed.

I have a fairly expensive piece of graphics animation software called “Lightwave”. It has the same “problem” as PreForm, but it’s not a code bug or an issue that escaped SQA. It’s just the way it is.

You certainly don’t need to delete your model when this happens, Josh. Just go to the Orient and reset all three axes to 0.

1 Like

Well, it depends on the application and needs. You have to remember the global axes too. And you have to do mental transformation for those as well - whenever you rotate the view. It’s really not a case of one being better (or worse) than the other.

That said, however, it’s the implementation that sucks. You have references for global (world) axes - well, at least for 1 of them (unless you’re in the Layout mode, then you get references for all 3). You don’t have any references for the local axes, though.

That won’t reset my patience quite as well as whacking the delete key :slight_smile:

1 Like

Saying this is not not a bug is simply handwaving. It’s a bug. Period. I only put the left wing on the plane. It’s an implementation limitation, not an actual bug.

ImplementationLimitation == BUG

I have an incredible piece of OpenSource software called Blender, and it does no such thing. It works exactly as you’d expect - always. And it works with my SpaceNavigator. And it moves smoothly, not jerky and clunky like Preform. And it works on Windows, Mac, Linux, and *BSD too. Blender is software done right by people who know how to write graphics software and use it themselves. Preform is glued together using someone elses core engine by people who seem like they’re learning how to write software, think everything needs to be as flat, ugly, and clunky as a web page, and apparently do not use real CAD or graphic programs - and it shows. Where has craftsmanship and pride in your work gone in this Country?

If they would simply port the code that works well (the support gen code is getting quite good now) into an addon for blender, then people could simply get blender for free, and run the Formlabs addon. All of the amazing graphics would come for free. The square wheel Formlabs has reinvented here is not scoring them any points.

I know I’m being belligerant, but dammit, this is really getting old. I’ve got work to do, and dicking around with stupid software is only getting in the way.

1 Like

Wow. You’re clearly frustrated by a real problem. But it’s hard to understand why you’re having so much difficulty. Your experience is totally opposite of mine. Yes, I’ve had lock occur when positioning a model, but it’s easy to correct. Like I said, you really only need two axes to orient the object, the third is superfluous, so whether or not it’s locked doesn’t matter. Just use the input boxes instead of the mouse. The mouse isn’t very precise anyway. I never really use it for orienting. Just for panning around the object.

But also, I don’t have the other issues you mentioned. If I click the up/down arrows or enter a new number in one of the orientation boxes, the image on the screen changes immediately. The boxes don’t do any of the random stuff you mention either.

As for Blender, while it’s a nice piece of Open Source, it’s not necessarily the best tool for CAD. If FormLabs was going to support direct printing from Blender, what else should they support? The development and sustaining engineering costs can add up quick. It’s much more economical (reduces the cost of the printer) to do it they way they’ve done it, stand alone, so that you can use whatever design tool you want and be able to print it. I use Lightwave for simple stuff, and SolidWorks for more involved stuff. A Blender plug in wouldn’t benefit me at all, and I’d be unhappy paying more for the printer so it could include this support.

It’s sent to the printer now, but holy cow it just took way too long to get it oriented the way I wanted. I was using the text boxes, not the mouse. Setting all to zero resets it, but also going into layout, moving the part a tad, and then going back to orient seems to do it too. It’s just substandard stuff and it really eats at me. It shouldn’t be this way.

Yeah, FL doing a blender plugin is never going to happen. And you’re right that blender for CAD is non-optimal, but it certainly can do it well once you ‘get it’. I really wish FL would take a more open stance and allow others write software for the printer too. I just cannot see how this would not be beneficial for everyone. What exactly are they afraid of? More printer sales?

1 Like

Actually, yes it does - if you switch from global to local transform mode :smile:

Like i’ve said, it’s nothing weird, broken or obscure. It’s not a bug. The fact you can’t choose between global and local and the lack of axis indicators is a bug (or, rather, a lack of a feature).


While I generally appreciate and agree with your views and comments on this forum, I’m not finding that here on this topic, which I must say is surprising for me.

Or view or normal or gimbal mode - but that’s not the point. The point is you are dealing with a fixed global space here, defined by the build platform. I’m adjusting objects to fit into that space. On what planet does a local coordinate system make sense in this context? If I was editing the object, then yes it is often useful to be in a local or view or normal coordinate system. But not here, and not in this context. It is simply a bad software design decision whose implementation is buggy. No amount of telling me it’s ‘not a bug’ makes it not a bug.

If it feels like a bug, and acts like a bug, and makes using the software difficult or impossible without resetting all axes to zero or deleting and re-adding the object - then it’s a bug.

1 Like

I believe what everybody is just saying here is that you’re absolutely right @ChristopherBarr! However, there is no possbile solution (with the help of the community). Like @JoshK mentions, there are workaround which will still frustrate you, but for now that’s the only way to work with Prefrom. I understand your frustrations, It’s always annoying when you work with a certain program and it doesn’t work as it “should”. I.e. Blender->Prefrom. I have the same problem with SolidWorks and Prefrom as the RIGHT and MIDDLE mouse button do the exact same opposite. Furthermore “zooming” is the other way around as well. I just cannot get used to that…
I could of course ask Preform what the %$@ they are doing, however, I’ll just have to accept it as this has been their choice (for now).

To conclude. You certainly have a point, but I would suggest asking for this “option” as a feature request. I should do the same if I get really frustrated concerning the use of the mouse and keyboard compared to SolidWorks.

Q: Why would the numerical entries change inexplicably to other (often with 2 decimal places defined) random numbers after leaving the dialog and then coming back to it!!!???

Like @Randy_Cohen mentioned, I don’t have this issue either. I wouldn’t know why the numerical entries change…

Q: Why does a user have to wait while you calculate and display the graphic orientation with each number typed!!!???

This most definitely seems hardware related. When I change my orientation it take a blink on an eye (perhaps even less) for the orientation to change. However, this of course doesn’t answer your question because you’re asking “why” it does that. Obviously that would be because the program is “stupid” and doesn’t know if you want to rotate the model 4 degrees or 45 degrees. It would be just as frustrating if you want to rotate it 4 degrees and have to wait a certain amount of time for Preform to realise; “Ok, he’s not going to type another digit, lets orient the part”. Of course you can always make a request for such an option, however, these are minor “things” which, when implementing a lot of those options, will make Prefrom less userfriendly, which is something Formlabs seem to want to keep.

I agree, if they switched to Global Axis things would sure be more intuitive.

The alternative is an Apply or OK button that needs to be pressed with every change. I am all for eliminating steps, so I like it how it is. I have to say though it is instant on my computer, there is no wait time. If you have wait time and that frustrates you, I definitely recommend a new computer costing around $1100. It will change your whole life compared to the budget computers.

This. I have never experienced a single stutter while using Preform, and I have even been manipulating models while a PhotoView 360 render is running in the background. You spent $3k+ on a printer. Dont waste it with a black friday special computer.

I think calling the orientation X/Y/Z is a bit misleading, but once you ‘get it’ its straight forward.

Just some life advice: direct attacks on something people like will not win you sympathy. Making software is hard work, and they are not going to give it to you just because you called people names.

I don’t know, i don’t find it that confusing, it might be because i think of it as applying rotation transforms on the object, one by one, instead of freely rotating the object in space. Then again, i am a bit weird, so it might just be me.

But i agree it should - at the very least - be an option, not the sole system available. I’m just saying that it’s not quite a bug, although you’re right, it might be an odd UX choice.

Yeah, I think everyone mostly agrees with me here, but it’s in my delivery of the news that people have any issue with. I agree, my filtering system needs some work. It’s not that I’m wrong, per se, but jeez, I coulda sanded the edges off a little first… Note taken.

OMG yes. I zoom the wrong way every time first. Drives me nuts. I think a lot of folks like it this way, but there really needs to be a preferences dialog where these kinds of things can be customized.

Right, no. I don’t expect it would just wait some random period then apply it either. That’s equally wrong. Think of a calculator; you wouldn’t expect it to start adding numbers and displaying the (incomplete) result before you were finished, right? Same here. Enter forces calculation (or tabbing out of the box also would do this). Enter would simply update the display with the numbers as entered. The cursor has not moved - it’s still right where it was. You could, for instance, type ‘4’, ‘enter’, then ‘5’, ‘enter’ to emulate the spastic stuff Preform does (if you really thought that was cool) just to get to 45 degrees. Point is, why does it do stupid stuff - not that ‘On my new Uber Boxen it’s so fast I don’t really notice’. I’ve used graphics programs on a Pentium 66 in DOS 6.2 that were tighter and more preformant (relative to the HW they had to work on). Just because the hardware is getting better and better, it’s not an excuse to create bloatware. This has apparently been forgotten.

Point taken, and I appreciate your engagement. To be more clear than I have been, I’m talking about ideas and implementations here - not people.

So, I do not use Windows or Mac, on purpose, for very valid reasons. If you do not know what those reasons might be, I can’t help you. You’ll have to investigate that on your own. I built my own computer that I run daily. It’s an i7 hex w/ 24GB of DDR3 ram, an ATI Radeon w/ 2GB DDR5 driving three 24" monitors @ 19200x1200, and it’s in this case: FT02
The system is on hardware RAID1 on SSDs, with more that 6TB of additional raid storage. The parts for my box cost north of 4k 3 years ago. I run Debian Linux with the Enlightenment window manager. My box is not new, but still seriously smokes. It has several useful years left in it. But I can’t use my printer without a windows or Mac box, which really sucks, since basically all it’s doing is copying data there and running it on the printer. A phone could do that. It’s not like they’re taking advantage of two-way communication that can’t occur on Linux or something. It’s just that that they commited to an off-the-shelf framework that does not support Linux or *BSD, and everything they do is constrained by that decision.

So, just to to print, I had to stand up another physical machine (the software won’t work in a kvm VM) with a purchased copy of Win7. It’s a 5yr old AMD @3400MHz w/ 8GB ram (which I also built). It’s really no slouch. It used to run 6 or so VMS at a time for linux dev. It does have the onboard ATI video though, but still, it has 1GB ram on the board. Preparing models for a print should not require a Cray supercomputer.


Sorry for coming off so harsh - I tend to fight fire with fire, which can be less than ideal :disappointed:

I was expecting a computer with 2GB of ram and an integrated GPU. There no reason your computer should even sneeze at PreForm. It runs quite well on my old laptop (2.2ghz dual core, 12GB ram, ancient Quadro GPU).

Are you setting up the job on your main i7 box and transferring the .form file to the AMD machine to send to the printer, or doing all of the supports etc on the AMD?

I export an STL from blender on Linux (i7) to a samba share. The win7 box mounts this share area as it’s ‘My Documents’ @ login. I open it in Preform, scale it (in order to correct z-axis error), orient it, support it and print it from there.