Layout all then orient all intersects parts!

Just upgraded an hour ago. I put two parts in the build, selected layout all, then orient all and the parts go through each other. continuously repeatable. while intersected, I then select layout all, they separate, then orient all intersects them again. if I keep hitting orient all, they change orientation, but always intersect. forever. it’s a new bug.

bump - anyone looking into this?

Can you share any screenshots or .FORM files that illustrate the problem? I know that’d be useful for our team.

unfortunately I cannot share images of my work, however, the part dimensions are roughly 1cm x 4cm x 5.5cm. I’m assuming that two rectanglular shapes of those dimensions would also exhibit this behavior. it is absolutely repeatable.

-C

edit: as a side note, these parts have a 1mm wall thickness.

Does the problem persist if you reverse the order of operations? Namely, orient the parts how you want them to be printed, generate supports, then do auto-layout.

Auto-layout works by finding a packing solution to your parts in their given orientation. Computing a solution that doesn’t intersect for all possible orientations would take a long time (and is actually a pretty difficult math/computer science algorithm problem).

Then why not force a re-layout if you detect an intersection after a re-orient?

Or, alternatively, if you detect an intersection after a re-orient, ditch the optimal packing and offset the intersecting parts just enough so they don’t intersect

@Steve_Thomas
Thanks for replying. Here’s my workflow:

  • I add parts to the build. They are never where I want them, or oriented how I want them.

  • I then do an auto-layout all to see how PreForm wants to arrange them on the platform. If that seems acceptable, I leave them there. If not, I may move them around a bit.

  • I then do an auto-orient all, again to see what PF thinks is best. Generally, I’m not in agreement and will tweak them a bit - often re-clicking ‘orient all’ many times to see how it changes before I end up doing it myself manually. I’m always puzzeled as to why it continues to randomly change. Orient seems like it should be an actual calculation based up a number of factors, such as:

  • individual part geometries

  • number of parts

  • positions of parts on build platform

  • ideally it’s tied to a tank profile, either manually set, or automagically determined by the printer via RFID or barcode or whatever. Possibly layout all is more in tune with the tank than orient. But honestly, I’m not all that convinced that these two commands need to be two commands at all. shift-click and drag during orient should just move the part - done.

But clicking Orient all should be calculated, and once clicked it should stay the same because ostensibly you’ve determined the best possible way to print them. Sure, I should be able to override that, but one would think it’s better than a random selection in the software.

One of the more annoying ‘features’ of orient is how xyz appears to be represented relative to the part. It seems tied to the actual part, not the space it’s in. Or something, but it’s not really clear. In some orientations, I notice incrementing x or z have the same effect - it’s really quite bizarre. I still am not quite sure what the notion of xyz actually means in preform.

Anyway, I’m not arguing that calculating every possible orientation for N parts in M possible layouts would be incredible time consuming. That’s fairly obvious. What I am saying is, if it doesn’t work, then it probably should be removed.

@Ante_Vukorepa yeah, that is a possible solution. But I really think orient should try to calculate an optimal orientation. Maybe allowing the user to select important areas to (try to, if possible) avoid putting a support on beforehand as well.

Also, as a side note, it’s not really clear what optimal packing means with two smallish parts. Given that repeated prints on the same location of PDMS will prematurely ruin the tank, it’s not really clear why the packing always puts the parts in basically the same location: e.g. centered front to back, and aligned to the hinge side.

Have you verified the orientation intersection bug yet?

These are some really good suggestions guys. I’ll make sure our Preform guys take a look at your comments.

Auto-layout tries to place parts towards the hinge side as that reduces the peel forces on parts and generally results in better prints.

I see the behavior that you are describing, and while not explicitly intended behavior, it’s a different use case than anticipated when these functions where designed.

Auto-orient looks to maximize printability based on supportability and part geometries. It does this calculation for each part independently of all the other parts. The orientation changes when Orient is clicked again because we recognize that the first orientation shown isn’t always the most desirable for the user, so Preform will allow you to step through a series of different orientations.

The thought process regarding workflow is using the tools in the sequence that they are laid out on the screen: Scaling, Orienting, Supporting, Layout, then Printing. Like I said earlier, I’ll make sure our algorithm guys take a look at your suggestions and see how we can continue to improve the usability of the software.

AKA It’s a ‘feature’! :smile:
I guess I can see your intention, as the buttons are located in a stack, but there is no enforcement of selection, e.g. it’s not like there’s a do this, next, do that, next,… etc. This would be a typical paradigm for that kind of thing.

So, if I keep clicking ‘orient’, it’ll show ‘n’ iterations until it’s back to the first selection? What is the value of ‘n’?

Yeah… Well, I can tell you that I never scale my stuff, and I would love to see how many engineers actually do, so having it as the first thing to do seems a bit odd to me anyway. As for enforcing a particular workflow, or only functioning correctly with a particular unenforced workflow, I would prefer the software didn’t do that. Honestly, I’ve never seen any program that wants you to do things in a particular order or things won’t work right simply by a tool bar’s icon order…

Steve, I know I’ve exploded in frustration a few times here on the forum with regard to the software, and my comments probably hurt some feelings. I’m sorry they were brusque and blunt. That being said, I do not think my critiques are incorrect. Inventing an entirely new UI paradigm at the same time you are trying to create an entirely new printer technology might be taking too big a bite for a small startup company to execute.

I also realize that you have a need to make a mark and be creative, and I do applaud that, but the usability of the program for the kinds of people who are willing to shell out $3k+ for the device, plus all the recurring costs is just nowhere near where it needs to be. I say this as help to you (and ultimately me), because I really want you to succeed. I really do not think the correct path forward is sanding and polishing the edges of the current application. Maybe it’s time to put PreForm in maintenance mode and start fresh on v2. With all you’ve learned so far, it’s generally faster to eliminate the accumulated technical debt by re-thinking the problem and starting over. Sure, some core code would make the transition, but the UI should be a re-think. I’m sure many devs there would love for that to happen.

-C

@Steve_Thomas
Also, while we’re here, can you please describe specifically, and in detail, the meaning of XYZ control/behavior as it relates to the parts themselves and the build volume?

Thanks,
-C