discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Re: Best practices for OpenSCAD + Blender

W
Whosawhatsis
Sat, Oct 15, 2022 2:04 AM

Btw, there were some posts about this a while ago, which seems to be the most promising thing I've seen: https://github.com/emogenet/scad2nodes

It didn't seem to be ready at the time, and it kinda looks like the author has abandoned it, but you might be able to get it to work...
On Oct 14, 2022, 18:59 -0700, neri-engineering via Discuss discuss@lists.openscad.org, wrote:


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
<forwarded_message.eml><forwarded_message.eml>

Btw, there were some posts about this a while ago, which seems to be the most promising thing I've seen: https://github.com/emogenet/scad2nodes It didn't seem to be ready at the time, and it kinda looks like the author has abandoned it, but you might be able to get it to work... On Oct 14, 2022, 18:59 -0700, neri-engineering via Discuss <discuss@lists.openscad.org>, wrote: > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org > <forwarded_message.eml><forwarded_message.eml>
N
neri-engineering
Sat, Oct 15, 2022 2:14 AM

That project you mention seems to take a different approach, which is to generate the CSG code in a different language/framework.

That's still avoiding the problem, which is that we're going to have to "know" all the offsets in Blender to animate it correctly, even though we already know the parameters in OpenSCAD already.

A good example of this is a screw and a nut. E.g. if we ignore translation offsets and only talk about translation delta, we see that it related to the thread pitch. E.g., an M5x0.5 thread will translate 0.5mm with every 360 degree rotation. So in addition to having the thread already modeled in Blender, we should know about the actual pitch if we are to animate the screwing in correctly. At the very least. You get the drift.

The lib you mention does not seem to address that problem.

I think I would stick to not re-doing the CSG operations in Blender, because often times they're fine-tuned to the particulars of OpenSCAD, not every sphere needs to be the same, even if the $fn is equal, depending on tool being used. Vertex alignment etc.

I think a good strategy would be to start with some sort of solid model in Blender, where the CSG operations have already occurred in OpenSCAD. The question is, how to animate the STL compiled parts in Blender, without re-defining all the offsets, thread pitches, complex angle calculations (e.g. universal joint), etc. This is why my gut tells me that an optimum strategy may be to render the whole scene in OpenSCAD but then texture the individual pieces of rendered scene somehow in Blender, based on some "label" that the piece has, whether it a per-piece label or a per-face label. Something like this.

Still thinking about this. Thanks for your input. Something to think about, definitely.

Sent with Proton Mail secure email.

------- Original Message -------
On Friday, October 14th, 2022 at 9:04 PM, Whosawhatsis whosawhatsis@gmail.com wrote:

Btw, there were some posts about this a while ago, which seems to be the most promising thing I've seen: https://github.com/emogenet/scad2nodes

It didn't seem to be ready at the time, and it kinda looks like the author has abandoned it, but you might be able to get it to work...
On Oct 14, 2022, 18:59 -0700, neri-engineering via Discuss discuss@lists.openscad.org, wrote:


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
<forwarded_message.eml><forwarded_message.eml>

That project you mention seems to take a different approach, which is to generate the CSG code in a different language/framework. That's still avoiding the problem, which is that we're going to have to "know" all the offsets in Blender to animate it correctly, even though we already know the parameters in OpenSCAD already. A good example of this is a screw and a nut. E.g. if we ignore translation offsets and only talk about translation delta, we see that it related to the thread pitch. E.g., an M5x0.5 thread will translate 0.5mm with every 360 degree rotation. So in addition to having the thread already modeled in Blender, we should know about the actual pitch if we are to animate the screwing in correctly. At the very least. You get the drift. The lib you mention does not seem to address that problem. I think I would stick to not re-doing the CSG operations in Blender, because often times they're fine-tuned to the particulars of OpenSCAD, not every sphere needs to be the same, even if the $fn is equal, depending on tool being used. Vertex alignment etc. I think a good strategy would be to start with some sort of solid model in Blender, where the CSG operations have already occurred in OpenSCAD. The question is, how to animate the STL compiled parts in Blender, without re-defining all the offsets, thread pitches, complex angle calculations (e.g. universal joint), etc. This is why my gut tells me that an optimum strategy may be to render the whole scene in OpenSCAD but then texture the individual pieces of rendered scene somehow in Blender, based on some "label" that the piece has, whether it a per-piece label or a per-face label. Something like this. Still thinking about this. Thanks for your input. Something to think about, definitely. Sent with [Proton Mail](https://proton.me/) secure email. ------- Original Message ------- On Friday, October 14th, 2022 at 9:04 PM, Whosawhatsis <whosawhatsis@gmail.com> wrote: > Btw, there were some posts about this a while ago, which seems to be the most promising thing I've seen: https://github.com/emogenet/scad2nodes > > It didn't seem to be ready at the time, and it kinda looks like the author has abandoned it, but you might be able to get it to work... > On Oct 14, 2022, 18:59 -0700, neri-engineering via Discuss <discuss@lists.openscad.org>, wrote: > >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> <forwarded_message.eml><forwarded_message.eml>