The components I’m using have multiple textures embedded, but only one face material that defines the orientation of each object, yet all objects maintain standard axis!
I’ve tried to get OCL to generate cut lists from these components, but I’m not having any luck:
Both of these are difficult, as necessary to generate other outputs, and even if I do, I can’t get OCL to maintain grain direction!
You have to comply to the assumptions made by the developers of OCL in order to get the best results:
Better yet, upload an example and @boris.beaulant might have some suggestions for ya…
That’s probably the best idea! I might see if @boris.beaulant will accept a PM to help sort a solution! Big cheers Mike!
Hi,
Length and grain direction
By default OpenCutList uses longest dimension of the part to set it as length. But by disabling the “Automatic orientation of parts”, it uses the internal component red axis to set it as length and then grain direction.
Material of the part
OpenCutList uses the material to know the type of part (solid wood, sheet good, dimensional). So without material it can only read part sizes.
If the “Smart assignment of material” option is enabled, OCL uses the following material priority :
So if you apply a material to the instance element, child materials or parent materials are ignored.
Hey Boris, thanks for your response!
So essentially the limitation of OCL is that materials must be applied to the parent component, even though the face is nominated as “Sheet Goods”, and irrespective of adjusting the model’s axis?
I’ve also tried to import a CSV file of the components to size, with Length, Width and Thickness set, which I’d imagine would suffice for OCL to do it’s wonderful work, but it still seems to demand the application of materials!
So in other words, OCL is inappropriate for our needs?
No, you can apply material on children faces if you want. But while a material is applied on component instance, children materials are ignored.
In your example internal face sheet good material is ignored mainly because a “WALL” material is applied on the instance.
Model axis doesn’t exist in component space. So only component axis can be use.
Maybe not if you can’t change anything in your component.
Of course, as mentioned before, OCL uses the material to know if part is of type sheet good, solid wood or dimensional. Cutting diagram behavior depends of this.
OCL manage more than just sheet good parts.
I have moved my takeoffs to OCL and allowed it to control all materials
this saves DC resources and is global
OCL can handle visibility and gives non report on groups which is advantageous
With materials you can add data that a DC can respond to, like Pine 90x45, LVL 150x63… after painting, a redraw will change the size to suit.
Currently this requires the use of a shortcut, or extension, after exiting “paint parts”
I wonder if can add to your code, to the instance after the material change ?
$dc_observers.get_latest_class.redraw_with_undo(a_instance)
Sorry mate, I was meaning the component axis, Duh!
Hey Phil! Mate I can certainly see that OCL is a “serious” bit of kit, I’m just enjoying playing with it as the interface is SO cool!
The problem with our components, the colour applied to the panel defines the use / position of each component in the build for installation and furthermore for checking. This works a treat in practice, though we seemingly then struggle but only limited to our use of OCL. I’m probably reluctant to override this material application, sadly!
Even excluding this limitation to our use, I do find OCL quite clunky in respect of using SU materials for applicaton of source type for all projects! The option to permit options for Type (OCL) by Item Code (DC) or other, and the selection of R/G/B axis to determine L/W/T in lieu of that predefined by OCL, would create further options for the community. Say for example, the setting of Item Code permits the material type “sheet goods” etc, and the Item Code is set with stock sizes and if any grain direction, the same can be followed by any item with similar Item Codes!
I trialled a browser based application, that deals with just geometry and grain quite well! It is NO WHERE near as powerful as OCL, but for creating cutlists it has some simple but serious advantages. One being the setting of grain direction for the sheet, and grain direction for pieces, or the selection of not to follow. See below!
Given the strength of this application, we’d pay handsomely if it worked for us, but I do understand the want to suit the masses!
Hi Richard,
Maybe, but using material bring a lot of benefits :
Using internal component axis to define the length, width and thickness also has advantages. SketchUp’s default behavior is to align the material texture to the component axes. So with a simple native feature the textures show the grain direction of the parts.
Don’t be offended by this. It will always be more profitable for everyone to have a software that seeks to offer the most common operating mode possible than to develop specific modules for each.
Specific developments are heavy and expensive to maintain and can conflict with each other.
Today, refusing this offer is not ignoring your need, it is forcing me to respond to it as best as possible for both of us: Not offering you a product that will cost you too much to maintain in the long term. And not creating a gas factory of this project for us.
Are you talking about a user-defined DC attribute?
OCL can set grain direction for the sheet and for each pieces.
It can even allow that for some pieces the grain does not matter.
Not to impose anything on you, but I feel like a tag would be more appropriate for this purpose.
Do you need that Blue = Length, Red = Width and Green = Thickness ?
I think the thing to be mindful of with our SIP components, the thing that makes it most difficult to morph to varied workflows, each component contains around 50 internal groups/materials to make up; Front face / Rear face / Left profile / Left structure / Right profile / Right structure… When taking on this project, I never realised I’d need to establish a catalogue of maybe 50 odd edge profiles! Cementitious SIPs are truly an absolute nightmare of details, though then double that as we also use weathertex for the cladding laminate. All stems from the panel supporting both cladding and lining, traditionally overclad OSB SIPs are seriously a non-issue on these details!
We had Dwighty fly over to Perth, to see if he could install the system to PlusSpec, he just threw his hands in the air!
Boris, you will never offend me, in fact I’m in absolute awe of what you have bought to the modelling app we all love! And I seriously am not looking for a fix to our particular problem (well, other than that, I need to deliver a solution to my client).
All that said, I’ve always been a lover of apps that offer, say in your case; List by Material / List by Geometry as options! I’ve been a SketchUp user since the days of Noah (V3), the idea for me that part orientation is bound by material, as such, feels foreign! In general, unless a component contains a sub-group, materials scale with the component. Meaning, say a face panel to a drawer if scaled vertically, the texture will also scale, leading to incorrect texture scaling if the cabinet is later rendered.
In my world, I’d probably issue the option for both and monitor, which is the most used / preferred. Much like A/B testing on a website or email newsletter! Mindful, I’d imagine simple geometry is far easier to deal with and, if offered, maybe likely the most commonly adopted.
If I look at it this way, MMC (Modern Methods of Construction) is gaining significant traction, a system that includes their workflow will also benefit! If we consider MMC informs “cabinetry” the outcome as “profit to you” also grows!
While also, I use multiple applications each day, such that alike most, I need to re-learn on the run, what I do find with OCL (and back at you on the, please don’t take offence) is a deep dive each time to work through getting grain to orientate! The interface offered to @pcmoor indicates just how simple it can be!
Thank you!
I’m afraid we’ve misunderstood each other on this point. Only the internal axes of the component can determine the orientation of the parts by OCL. Their material will only indicate whether there is a grain to follow or not. And this attribute make sens only in cutting diagrams.
What you need to keep in mind is that CutList Optimizer only considers parts in 2D. So adding one grain attribute is easier because there’s only 2 choices : length or width.
Opposite, SketchUp is a 3D software. So OpenCutList must be able to read part data from 3D solid. The minimal data we can export from 3D solid is its bounding box, a 3D rectangular parallelepiped that hold 3 dimensions. So we have to find a way to choose which is length, width and thickness.
OpenCutList permits 2 stratégies for this :
The second strategy allows the user to do exactly what he want, just by orienting the axis. And this using a native functionality.
Of course this convention is arbitrary. But in most geometry software or maths problem, X= length, Y= width and Z= thickness. So it try to fit to a commun convention.
Now using the length to obtain grain direction comes from 3 ideas :
Else, out of the DC world, OpenCutList bring a one click tool to see and change grain orientation.
I know that any changes on your DC could be a big job. But to fit OCL convention you only need 2 changes :
Thanks Boris for this insight!
The problem we have, the colour applied to the panel defines its type and is set by the DC, eg: Wall, Sill, Lintel etc. and needs to be on top of the panel so to be visible in plan view!
It could just be our case, but it seems to simply have the option to match geometry (blue axis) to sheet length, would help cover almost all other use cases, those cases such as ours! I know when I say simple, this could be a lot of work! Its crazy, immediately everything populates with all the correct info, we just cant click a button to generate a cutlist! 
I understand this may be outside your general case, I’m just looking for an option to use what is a serious bit of software! We have easily adopted to the use of Cutlist Optimizer, as it does the job very simply, I just feel to be missing out on the fun!
All that said, you’ve done an AMAZING job! 
Hmm, nothing is never impossible … just design the DC differently :
panel_compatible_ocl.skp (93,5 Ko)
The length along red axis convention is a simple rule for users to understand as for implementing it in the code.
Adding an option to customize this brings a huge number of cases to solve everywhere in the code.
It has little interest to solve a problem that can be solved at the source by defining the dynamic component differently.
I repeat myself, but the material is the basis of how OpenCutList works. This is how it is able to define the part type.
It is totally impossible to have an “Ignore material assignments” option, because in this case, it amounts to not putting any material and therefore not knowing that the part is of type “Panel”.
“Set part axis to follow sheet length” doesn’t make sens too, because a part is not necessary a panel. It can be a piece of solid wood, dimensional or hardware part.
For option “Sort parts by thickness or something else”, it’s exactly what the second dialog tab do …
Mate, I’ll send you a message!! We cant change axis as it throws so many other parts out of whack! We work on the blue axis worked to height as per SketchUp normals!! We also can’t as per your supplied model make the top section of the panel a group as we count on being able to modify left and right edges of any component to suit the top edge being raked!
