JC
John Colagioia
Tue, Jan 28, 2025 11:13 PM
Hi, I'm new (but reading along for the last few days), so I apologize if
I violate some cultural norm or ask a question that I'm supposed to know.
That said, here's the short version: Might anybody know how to use an
object from another application (Makehuman
http://www.makehumancommunity.org/, in my case) in a way that works
more or less like OpenSCAD's native objects?
For example, if I export an STL file from Makehuman, I can import() it
into OpenSCAD, yes. However, if I apply an intersection() or
difference() operation to take just the head or an arm, the surface-mesh
aspect of STL files gets exposed, with a gaping hole along the
separation plane and parts of the remaining surface looking see-through
like what happens when taking the difference between two native objects
of similar sizes.
Overall, I want something like action figure or doll parts. For
example, I might want to take the character's head as a separate object
and add a peg to the bottom so that a printed version can rotate in a
neck socket. I can do that with loose geometric approximations of the
human form
(https://codeberg.org/jcolag/lights-edge-toys/src/branch/main/LLL-1/lll-1.scad
as my hacky proof-of-concept), but can't figure out how to get OpenSCAD
to treat the imported object as a solid thing.
I tried checking with Makehuman, Blender, and FreeCAD people, thinking
that I could do something upstream before import, but they only
understood that printing a closed mesh will give a solid pile of
plastic. Or they had voxel things that required such high computational
loads that my laptop couldn't complete the task.
Thanks!
Hi, I'm new (but reading along for the last few days), so I apologize if
I violate some cultural norm or ask a question that I'm supposed to know.
That said, here's the short version: Might anybody know how to use an
object from another application (Makehuman
<http://www.makehumancommunity.org/>, in my case) in a way that works
more or less like OpenSCAD's native objects?
For example, if I export an STL file from Makehuman, I can import() it
into OpenSCAD, yes. However, if I apply an intersection() or
difference() operation to take just the head or an arm, the surface-mesh
aspect of STL files gets exposed, with a gaping hole along the
separation plane and parts of the remaining surface looking see-through
like what happens when taking the difference between two native objects
of similar sizes.
Overall, I want something like action figure or doll parts. For
example, I might want to take the character's head as a separate object
and add a peg to the bottom so that a printed version can rotate in a
neck socket. I can do that with loose geometric approximations of the
human form
(https://codeberg.org/jcolag/lights-edge-toys/src/branch/main/LLL-1/lll-1.scad
as my hacky proof-of-concept), but can't figure out how to get OpenSCAD
to treat the imported object as a solid thing.
I tried checking with Makehuman, Blender, and FreeCAD people, thinking
that I could do something upstream before import, but they only
understood that printing a closed mesh will give a solid pile of
plastic. Or they had voxel things that required such high computational
loads that my laptop couldn't complete the task.
Thanks!
DP
David Phillip Oster
Wed, Jan 29, 2025 5:07 AM
Hi, I'm new (but reading along for the last few days), so I apologize if I
violate some cultural norm or ask a question that I'm supposed to know.
That said, here's the short version: Might anybody know how to use an
object from another application (Makehuman
http://www.makehumancommunity.org/, in my case) in a way that works
more or less like OpenSCAD's native objects?
For example, if I export an STL file from Makehuman, I can import() it
into OpenSCAD, yes. However, if I apply an intersection() or difference()
operation to take just the head or an arm, the surface-mesh aspect of STL
files gets exposed, with a gaping hole along the separation plane and parts
of the remaining surface looking see-through like what happens when taking
the difference between two native objects of similar sizes.
My first thought is that it would be easy to read an .stl file in as the
OpenSCAD BOSL2 <https://github.com/BelfrySCAD/BOSL2>'s vnf (an array of: an
array of vertices and an array of faces (where a face is an array of
indexes into the vertices)), maybe with a little adapter program, (and that
is very close to the .obj file format anyway) but I don't think BOSL2 has a
lot of support for repairing meshes.
I use an old, but still functional app, Meshmixer
<https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/How-to-download-Meshmixer.html>.
But I'm under the impression that it has some security vulnerabilities. It
*is* good for repairing meshes. See Meshmixer - Editing and Combining
<https://www.youtube.com/watch?v=JPiKf1APe1I> [9 min] or Fixing impossible
STL's with Meshmixer <https://www.youtube.com/watch?v=8ECNP3WN_-Q> [20 min]
for more information.
On Tue, Jan 28, 2025 at 7:04 PM John Colagioia via Discuss <
discuss@lists.openscad.org> wrote:
> Hi, I'm new (but reading along for the last few days), so I apologize if I
> violate some cultural norm or ask a question that I'm supposed to know.
>
> That said, here's the short version: Might anybody know how to use an
> object from another application (Makehuman
> <http://www.makehumancommunity.org/>, in my case) in a way that works
> more or less like OpenSCAD's native objects?
>
> For example, if I export an STL file from Makehuman, I can import() it
> into OpenSCAD, yes. However, if I apply an intersection() or difference()
> operation to take just the head or an arm, the surface-mesh aspect of STL
> files gets exposed, with a gaping hole along the separation plane and parts
> of the remaining surface looking see-through like what happens when taking
> the difference between two native objects of similar sizes.
>
JB
Jordan Brown
Wed, Jan 29, 2025 5:09 AM
On 1/28/2025 3:13 PM, John Colagioia via Discuss wrote:
Hi, I'm new (but reading along for the last few days), so I apologize
if I violate some cultural norm or ask a question that I'm supposed to
know.
No worries, that's pretty rare. You might sometimes not like the
answers ("sorry, you need to understand how to write a program" or
"sorry, you need to learn high school math to work effectively with
trigonometry") but we're generally pretty good about not taking offense.
That said, here's the short version: Might anybody know how to use an
object from another application (Makehuman
http://www.makehumancommunity.org/, in my case) in a way that works
more or less like OpenSCAD's native objects?
You're already on the right track with import(). import() is more or
less equivalent to polyhedron(), except that the data comes from a file.
For example, if I export an STL file from Makehuman, I can import() it
into OpenSCAD, yes. However, if I apply an intersection() or
difference() operation to take just the head or an arm, the
surface-mesh aspect of STL files gets exposed, with a gaping hole
along the separation plane and parts of the remaining surface looking
see-through like what happens when taking the difference between two
native objects of similar sizes.
Mostly, OpenSCAD only works with solids.
If you're seeing gaping meshes, it suggests one of two things:
- What you gave it wasn't a valid mesh to begin with. Unfortunately,
OpenSCAD is pickier than a lot of other consumers. It may also have
issues with very small (~10^-6) details.
- The previewer has trouble when the camera is inside the model,
notably including when it is inside invisible parts of the model. A
common issue is differencing away a large cube and then having
trouble when you position the camera inside that invisible cube.
Similarly, there can be issues if you intersect with a large cube
and then put the camera inside that cube.
One simple check for whether OpenSCAD is unhappy with your mesh is to
attempt to union it with anything, typically a small cube, and render.
import("myfile.stl");
cube();
then press F6 to render. If you end up with something that looks like
your mesh, you're golden. If you end up with nothing and error messages
in the OpenSCAD console, not so good.
If you supply a sample mesh, somebody can experiment with it a bit.
Some of us have tools for identifying problems... but I'm not one of them.
On 1/28/2025 3:13 PM, John Colagioia via Discuss wrote:
>
> Hi, I'm new (but reading along for the last few days), so I apologize
> if I violate some cultural norm or ask a question that I'm supposed to
> know.
>
No worries, that's pretty rare. You might sometimes not *like* the
answers ("sorry, you need to understand how to write a program" or
"sorry, you need to learn high school math to work effectively with
trigonometry") but we're generally pretty good about not taking offense.
> That said, here's the short version: Might anybody know how to use an
> object from another application (Makehuman
> <http://www.makehumancommunity.org/>, in my case) in a way that works
> more or less like OpenSCAD's native objects?
>
You're already on the right track with import(). import() is more or
less equivalent to polyhedron(), except that the data comes from a file.
> For example, if I export an STL file from Makehuman, I can import() it
> into OpenSCAD, yes. However, if I apply an intersection() or
> difference() operation to take just the head or an arm, the
> surface-mesh aspect of STL files gets exposed, with a gaping hole
> along the separation plane and parts of the remaining surface looking
> see-through like what happens when taking the difference between two
> native objects of similar sizes.
>
Mostly, OpenSCAD only works with solids.
If you're seeing gaping meshes, it suggests one of two things:
* What you gave it wasn't a valid mesh to begin with. Unfortunately,
OpenSCAD is pickier than a lot of other consumers. It may also have
issues with very small (~10^-6) details.
* The previewer has trouble when the camera is inside the model,
notably including when it is inside invisible parts of the model. A
common issue is differencing away a large cube and then having
trouble when you position the camera inside that invisible cube.
Similarly, there can be issues if you intersect with a large cube
and then put the camera inside *that* cube.
One simple check for whether OpenSCAD is unhappy with your mesh is to
attempt to union it with anything, typically a small cube, and render.
import("myfile.stl");
cube();
then press F6 to render. If you end up with something that looks like
your mesh, you're golden. If you end up with nothing and error messages
in the OpenSCAD console, not so good.
If you supply a sample mesh, somebody can experiment with it a bit.
Some of us have tools for identifying problems... but I'm not one of them.
RW
Raymond West
Wed, Jan 29, 2025 12:29 PM
Exactly as Jordan stated. I've no experience of the make human files,
but in general many of the files you find on the web are broken.
Judicious use of something like Meshlab, or other tools can repair them.
Most users will not know that a file is not manifold, since many slicers
work around it. If the file is solid, then I have found that all the
features of openscad work with it, difference/intersection/ whatever.
On 29/01/2025 05:09, Jordan Brown via Discuss wrote:
On 1/28/2025 3:13 PM, John Colagioia via Discuss wrote:
Hi, I'm new (but reading along for the last few days), so I apologize
if I violate some cultural norm or ask a question that I'm supposed
to know.
No worries, that's pretty rare. You might sometimes not like the
answers ("sorry, you need to understand how to write a program" or
"sorry, you need to learn high school math to work effectively with
trigonometry") but we're generally pretty good about not taking offense.
That said, here's the short version: Might anybody know how to use
an object from another application (Makehuman
http://www.makehumancommunity.org/, in my case) in a way that works
more or less like OpenSCAD's native objects?
You're already on the right track with import(). import() is more or
less equivalent to polyhedron(), except that the data comes from a file.
For example, if I export an STL file from Makehuman, I can import()
it into OpenSCAD, yes. However, if I apply an intersection() or
difference() operation to take just the head or an arm, the
surface-mesh aspect of STL files gets exposed, with a gaping hole
along the separation plane and parts of the remaining surface looking
see-through like what happens when taking the difference between two
native objects of similar sizes.
Mostly, OpenSCAD only works with solids.
If you're seeing gaping meshes, it suggests one of two things:
- What you gave it wasn't a valid mesh to begin with. Unfortunately,
OpenSCAD is pickier than a lot of other consumers. It may also
have issues with very small (~10^-6) details.
- The previewer has trouble when the camera is inside the model,
notably including when it is inside invisible parts of the model.
A common issue is differencing away a large cube and then having
trouble when you position the camera inside that invisible cube.
Similarly, there can be issues if you intersect with a large cube
and then put the camera inside that cube.
One simple check for whether OpenSCAD is unhappy with your mesh is to
attempt to union it with anything, typically a small cube, and render.
import("myfile.stl");
cube();
then press F6 to render. If you end up with something that looks like
your mesh, you're golden. If you end up with nothing and error
messages in the OpenSCAD console, not so good.
If you supply a sample mesh, somebody can experiment with it a bit.
Some of us have tools for identifying problems... but I'm not one of them.
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
Exactly as Jordan stated. I've no experience of the make human files,
but in general many of the files you find on the web are broken.
Judicious use of something like Meshlab, or other tools can repair them.
Most users will not know that a file is not manifold, since many slicers
work around it. If the file is solid, then I have found that all the
features of openscad work with it, difference/intersection/ whatever.
On 29/01/2025 05:09, Jordan Brown via Discuss wrote:
> On 1/28/2025 3:13 PM, John Colagioia via Discuss wrote:
>>
>> Hi, I'm new (but reading along for the last few days), so I apologize
>> if I violate some cultural norm or ask a question that I'm supposed
>> to know.
>>
>
> No worries, that's pretty rare. You might sometimes not *like* the
> answers ("sorry, you need to understand how to write a program" or
> "sorry, you need to learn high school math to work effectively with
> trigonometry") but we're generally pretty good about not taking offense.
>
>> That said, here's the short version: Might anybody know how to use
>> an object from another application (Makehuman
>> <http://www.makehumancommunity.org/>, in my case) in a way that works
>> more or less like OpenSCAD's native objects?
>>
>
> You're already on the right track with import(). import() is more or
> less equivalent to polyhedron(), except that the data comes from a file.
>
>> For example, if I export an STL file from Makehuman, I can import()
>> it into OpenSCAD, yes. However, if I apply an intersection() or
>> difference() operation to take just the head or an arm, the
>> surface-mesh aspect of STL files gets exposed, with a gaping hole
>> along the separation plane and parts of the remaining surface looking
>> see-through like what happens when taking the difference between two
>> native objects of similar sizes.
>>
>
> Mostly, OpenSCAD only works with solids.
>
> If you're seeing gaping meshes, it suggests one of two things:
>
> * What you gave it wasn't a valid mesh to begin with. Unfortunately,
> OpenSCAD is pickier than a lot of other consumers. It may also
> have issues with very small (~10^-6) details.
> * The previewer has trouble when the camera is inside the model,
> notably including when it is inside invisible parts of the model.
> A common issue is differencing away a large cube and then having
> trouble when you position the camera inside that invisible cube.
> Similarly, there can be issues if you intersect with a large cube
> and then put the camera inside *that* cube.
>
> One simple check for whether OpenSCAD is unhappy with your mesh is to
> attempt to union it with anything, typically a small cube, and render.
>
> import("myfile.stl");
> cube();
>
> then press F6 to render. If you end up with something that looks like
> your mesh, you're golden. If you end up with nothing and error
> messages in the OpenSCAD console, not so good.
>
>
> If you supply a sample mesh, somebody can experiment with it a bit.
> Some of us have tools for identifying problems... but I'm not one of them.
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email todiscuss-leave@lists.openscad.org
RV
Roel Vanhout
Wed, Jan 29, 2025 1:21 PM
If you don't want to use Meshmixer, I did have good experiences using
Blender and the '3d printing' plugin which has tools to check for mesh
manifoldness, as well as tools to fix issues automatically; the advantage
of Blender is that you can manually fix things if the automatic procedures
don't do what you want. But that is also the biggest danger of using
Blender, sometimes I fall into a trap of making all sorts of manual
adjustments that just make things worse and/or are a massive time waster.
But you mentioned you already tried Blender - not sure if you used the '3d
printing' plugin?
On Wed, Jan 29, 2025 at 1:30 PM Raymond West via Discuss <
discuss@lists.openscad.org> wrote:
Exactly as Jordan stated. I've no experience of the make human files, but
in general many of the files you find on the web are broken. Judicious use
of something like Meshlab, or other tools can repair them. Most users will
not know that a file is not manifold, since many slicers work around it. If
the file is solid, then I have found that all the features of openscad work
with it, difference/intersection/ whatever.
On 29/01/2025 05:09, Jordan Brown via Discuss wrote:
On 1/28/2025 3:13 PM, John Colagioia via Discuss wrote:
Hi, I'm new (but reading along for the last few days), so I apologize if I
violate some cultural norm or ask a question that I'm supposed to know.
No worries, that's pretty rare. You might sometimes not like the
answers ("sorry, you need to understand how to write a program" or "sorry,
you need to learn high school math to work effectively with trigonometry")
but we're generally pretty good about not taking offense.
That said, here's the short version: Might anybody know how to use an
object from another application (Makehuman
http://www.makehumancommunity.org/, in my case) in a way that works
more or less like OpenSCAD's native objects?
You're already on the right track with import(). import() is more or less
equivalent to polyhedron(), except that the data comes from a file.
For example, if I export an STL file from Makehuman, I can import() it
into OpenSCAD, yes. However, if I apply an intersection() or difference()
operation to take just the head or an arm, the surface-mesh aspect of STL
files gets exposed, with a gaping hole along the separation plane and parts
of the remaining surface looking see-through like what happens when taking
the difference between two native objects of similar sizes.
Mostly, OpenSCAD only works with solids.
If you're seeing gaping meshes, it suggests one of two things:
- What you gave it wasn't a valid mesh to begin with. Unfortunately,
OpenSCAD is pickier than a lot of other consumers. It may also have issues
with very small (~10^-6) details.
- The previewer has trouble when the camera is inside the model,
notably including when it is inside invisible parts of the model. A common
issue is differencing away a large cube and then having trouble when you
position the camera inside that invisible cube. Similarly, there can be
issues if you intersect with a large cube and then put the camera inside
*that* cube.
One simple check for whether OpenSCAD is unhappy with your mesh is to
attempt to union it with anything, typically a small cube, and render.
import("myfile.stl");
cube();
then press F6 to render. If you end up with something that looks like
your mesh, you're golden. If you end up with nothing and error messages in
the OpenSCAD console, not so good.
If you supply a sample mesh, somebody can experiment with it a bit. Some
of us have tools for identifying problems... but I'm not one of them.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
If you don't want to use Meshmixer, I did have good experiences using
Blender and the '3d printing' plugin which has tools to check for mesh
manifoldness, as well as tools to fix issues automatically; the advantage
of Blender is that you can manually fix things if the automatic procedures
don't do what you want. But that is also the biggest danger of using
Blender, sometimes I fall into a trap of making all sorts of manual
adjustments that just make things worse and/or are a massive time waster.
But you mentioned you already tried Blender - not sure if you used the '3d
printing' plugin?
On Wed, Jan 29, 2025 at 1:30 PM Raymond West via Discuss <
discuss@lists.openscad.org> wrote:
> Exactly as Jordan stated. I've no experience of the make human files, but
> in general many of the files you find on the web are broken. Judicious use
> of something like Meshlab, or other tools can repair them. Most users will
> not know that a file is not manifold, since many slicers work around it. If
> the file is solid, then I have found that all the features of openscad work
> with it, difference/intersection/ whatever.
> On 29/01/2025 05:09, Jordan Brown via Discuss wrote:
>
> On 1/28/2025 3:13 PM, John Colagioia via Discuss wrote:
>
> Hi, I'm new (but reading along for the last few days), so I apologize if I
> violate some cultural norm or ask a question that I'm supposed to know.
>
>
> No worries, that's pretty rare. You might sometimes not *like* the
> answers ("sorry, you need to understand how to write a program" or "sorry,
> you need to learn high school math to work effectively with trigonometry")
> but we're generally pretty good about not taking offense.
>
> That said, here's the short version: Might anybody know how to use an
> object from another application (Makehuman
> <http://www.makehumancommunity.org/>, in my case) in a way that works
> more or less like OpenSCAD's native objects?
>
>
> You're already on the right track with import(). import() is more or less
> equivalent to polyhedron(), except that the data comes from a file.
>
> For example, if I export an STL file from Makehuman, I can import() it
> into OpenSCAD, yes. However, if I apply an intersection() or difference()
> operation to take just the head or an arm, the surface-mesh aspect of STL
> files gets exposed, with a gaping hole along the separation plane and parts
> of the remaining surface looking see-through like what happens when taking
> the difference between two native objects of similar sizes.
>
>
> Mostly, OpenSCAD only works with solids.
>
> If you're seeing gaping meshes, it suggests one of two things:
>
> - What you gave it wasn't a valid mesh to begin with. Unfortunately,
> OpenSCAD is pickier than a lot of other consumers. It may also have issues
> with very small (~10^-6) details.
> - The previewer has trouble when the camera is inside the model,
> notably including when it is inside invisible parts of the model. A common
> issue is differencing away a large cube and then having trouble when you
> position the camera inside that invisible cube. Similarly, there can be
> issues if you intersect with a large cube and then put the camera inside
> *that* cube.
>
> One simple check for whether OpenSCAD is unhappy with your mesh is to
> attempt to union it with anything, typically a small cube, and render.
>
> import("myfile.stl");
> cube();
>
> then press F6 to render. If you end up with something that looks like
> your mesh, you're golden. If you end up with nothing and error messages in
> the OpenSCAD console, not so good.
>
>
> If you supply a sample mesh, somebody can experiment with it a bit. Some
> of us have tools for identifying problems... but I'm not one of them.
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
JB
Jon Bondy
Wed, Jan 29, 2025 1:46 PM
I tried Blender in an attempt to smooth a 3D scan. Despite being in
Sculpt mode, none of the smoothing changes that I made (and were
visible) were ever reflected in the files that I then exported. Blender
did nothing (after I spent a LOT of time thinking that I had actually
been smoothing). And the Blender community was unable to help at all.
MeshMixer was also unable to smooth my model at all, despite many videos
showing that it worked. I ended up using SculptGL. An orphan program,
but at least it works.
If you install AngelCAD, you will get a command line program, PolyFix,
which can fix many things with bad models.
Jon
On 1/29/2025 8:21 AM, Roel Vanhout via Discuss wrote:
If you don't want to use Meshmixer, I did have good experiences using
Blender and the '3d printing' plugin which has tools to check for mesh
manifoldness, as well as tools to fix issues automatically; the
advantage of Blender is that you can manually fix things if the
automatic procedures don't do what you want. But that is also the
biggest danger of using Blender, sometimes I fall into a trap of
making all sorts of manual adjustments that just make things worse
and/or are a massive time waster.
But you mentioned you already tried Blender - not sure if you used the
'3d printing' plugin?
On Wed, Jan 29, 2025 at 1:30 PM Raymond West via Discuss
discuss@lists.openscad.org wrote:
Exactly as Jordan stated. I've no experience of the make human
files, but in general many of the files you find on the web are
broken. Judicious use of something like Meshlab, or other tools
can repair them. Most users will not know that a file is not
manifold, since many slicers work around it. If the file is solid,
then I have found that all the features of openscad work with it,
difference/intersection/ whatever.
On 29/01/2025 05:09, Jordan Brown via Discuss wrote:
On 1/28/2025 3:13 PM, John Colagioia via Discuss wrote:
Hi, I'm new (but reading along for the last few days), so I
apologize if I violate some cultural norm or ask a question that
I'm supposed to know.
No worries, that's pretty rare. You might sometimes not *like*
the answers ("sorry, you need to understand how to write a
program" or "sorry, you need to learn high school math to work
effectively with trigonometry") but we're generally pretty good
about not taking offense.
That said, here's the short version: Might anybody know how to
use an object from another application (Makehuman
<http://www.makehumancommunity.org/>, in my case) in a way that
works more or less like OpenSCAD's native objects?
You're already on the right track with import(). import() is
more or less equivalent to polyhedron(), except that the data
comes from a file.
For example, if I export an STL file from Makehuman, I can
import() it into OpenSCAD, yes. However, if I apply an
intersection() or difference() operation to take just the head
or an arm, the surface-mesh aspect of STL files gets exposed,
with a gaping hole along the separation plane and parts of the
remaining surface looking see-through like what happens when
taking the difference between two native objects of similar sizes.
Mostly, OpenSCAD only works with solids.
If you're seeing gaping meshes, it suggests one of two things:
* What you gave it wasn't a valid mesh to begin with.
Unfortunately, OpenSCAD is pickier than a lot of other
consumers. It may also have issues with very small (~10^-6)
details.
* The previewer has trouble when the camera is inside the
model, notably including when it is inside invisible parts of
the model. A common issue is differencing away a large cube
and then having trouble when you position the camera inside
that invisible cube. Similarly, there can be issues if you
intersect with a large cube and then put the camera inside
*that* cube.
One simple check for whether OpenSCAD is unhappy with your mesh
is to attempt to union it with anything, typically a small cube,
and render.
import("myfile.stl");
cube();
then press F6 to render. If you end up with something that looks
like your mesh, you're golden. If you end up with nothing and
error messages in the OpenSCAD console, not so good.
If you supply a sample mesh, somebody can experiment with it a
bit. Some of us have tools for identifying problems... but I'm
not one of them.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
I tried Blender in an attempt to smooth a 3D scan. Despite being in
Sculpt mode, none of the smoothing changes that I made (and were
visible) were ever reflected in the files that I then exported. Blender
did nothing (after I spent a LOT of time thinking that I had actually
been smoothing). And the Blender community was unable to help at all.
MeshMixer was also unable to smooth my model at all, despite many videos
showing that it worked. I ended up using SculptGL. An orphan program,
but at least it works.
If you install AngelCAD, you will get a command line program, PolyFix,
which can fix many things with bad models.
Jon
On 1/29/2025 8:21 AM, Roel Vanhout via Discuss wrote:
> If you don't want to use Meshmixer, I did have good experiences using
> Blender and the '3d printing' plugin which has tools to check for mesh
> manifoldness, as well as tools to fix issues automatically; the
> advantage of Blender is that you can manually fix things if the
> automatic procedures don't do what you want. But that is also the
> biggest danger of using Blender, sometimes I fall into a trap of
> making all sorts of manual adjustments that just make things worse
> and/or are a massive time waster.
>
> But you mentioned you already tried Blender - not sure if you used the
> '3d printing' plugin?
>
>
> On Wed, Jan 29, 2025 at 1:30 PM Raymond West via Discuss
> <discuss@lists.openscad.org> wrote:
>
> Exactly as Jordan stated. I've no experience of the make human
> files, but in general many of the files you find on the web are
> broken. Judicious use of something like Meshlab, or other tools
> can repair them. Most users will not know that a file is not
> manifold, since many slicers work around it. If the file is solid,
> then I have found that all the features of openscad work with it,
> difference/intersection/ whatever.
>
> On 29/01/2025 05:09, Jordan Brown via Discuss wrote:
>> On 1/28/2025 3:13 PM, John Colagioia via Discuss wrote:
>>>
>>> Hi, I'm new (but reading along for the last few days), so I
>>> apologize if I violate some cultural norm or ask a question that
>>> I'm supposed to know.
>>>
>>
>> No worries, that's pretty rare. You might sometimes not *like*
>> the answers ("sorry, you need to understand how to write a
>> program" or "sorry, you need to learn high school math to work
>> effectively with trigonometry") but we're generally pretty good
>> about not taking offense.
>>
>>> That said, here's the short version: Might anybody know how to
>>> use an object from another application (Makehuman
>>> <http://www.makehumancommunity.org/>, in my case) in a way that
>>> works more or less like OpenSCAD's native objects?
>>>
>>
>> You're already on the right track with import(). import() is
>> more or less equivalent to polyhedron(), except that the data
>> comes from a file.
>>
>>> For example, if I export an STL file from Makehuman, I can
>>> import() it into OpenSCAD, yes. However, if I apply an
>>> intersection() or difference() operation to take just the head
>>> or an arm, the surface-mesh aspect of STL files gets exposed,
>>> with a gaping hole along the separation plane and parts of the
>>> remaining surface looking see-through like what happens when
>>> taking the difference between two native objects of similar sizes.
>>>
>>
>> Mostly, OpenSCAD only works with solids.
>>
>> If you're seeing gaping meshes, it suggests one of two things:
>>
>> * What you gave it wasn't a valid mesh to begin with.
>> Unfortunately, OpenSCAD is pickier than a lot of other
>> consumers. It may also have issues with very small (~10^-6)
>> details.
>> * The previewer has trouble when the camera is inside the
>> model, notably including when it is inside invisible parts of
>> the model. A common issue is differencing away a large cube
>> and then having trouble when you position the camera inside
>> that invisible cube. Similarly, there can be issues if you
>> intersect with a large cube and then put the camera inside
>> *that* cube.
>>
>> One simple check for whether OpenSCAD is unhappy with your mesh
>> is to attempt to union it with anything, typically a small cube,
>> and render.
>>
>> import("myfile.stl");
>> cube();
>>
>> then press F6 to render. If you end up with something that looks
>> like your mesh, you're golden. If you end up with nothing and
>> error messages in the OpenSCAD console, not so good.
>>
>>
>> If you supply a sample mesh, somebody can experiment with it a
>> bit. Some of us have tools for identifying problems... but I'm
>> not one of them.
>>
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email todiscuss-leave@lists.openscad.org
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email todiscuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
R
richard@milewski.org
Mon, Feb 3, 2025 8:54 PM
If I remember correctly the security issues with Meshmixer were with the downloader for the Mac version. That’s why the download page still has a Windows .exe but nothing for the Mac.
If I remember correctly the security issues with Meshmixer were with the downloader for the Mac version. That’s why the download page still has a Windows .exe but nothing for the Mac.
JC
John Colagioia
Sat, Feb 15, 2025 8:17 PM
It took me forever to run some tests and revisit this, but I did want to
check back in to thank everyone for their thoughts on this. While I
haven't tried an actual print, yet, it looks like repairing the mesh -
FreeCAD's Evaluate & Repair Mesh tool, here; I've tried Blender's plugin
before, and it looks similar (but no Meshmixer on Linux) - PLUS the
convexity parameter comes pretty close for the default Makehuman model.
That's just bisecting (difference with a cube) the default model with no
proportions/identity elements set or accessories added, but good enough
for a proof of concept. The floating bits on the image's right, and the
white/transparent areas make me a /little/ suspicious, but they're now
tiny, localized spots instead of the entire model like that.
Again, thanks, everyone!
On 1/29/25 08:21, Roel Vanhout via Discuss wrote:
If you don't want to use Meshmixer, I did have good experiences using
Blender and the '3d printing' plugin which has tools to check for mesh
manifoldness, as well as tools to fix issues automatically; the
advantage of Blender is that you can manually fix things if the
automatic procedures don't do what you want. But that is also the
biggest danger of using Blender, sometimes I fall into a trap of
making all sorts of manual adjustments that just make things worse
and/or are a massive time waster.
But you mentioned you already tried Blender - not sure if you used the
'3d printing' plugin?
On Wed, Jan 29, 2025 at 1:30 PM Raymond West via Discuss
discuss@lists.openscad.org wrote:
Exactly as Jordan stated. I've no experience of the make human
files, but in general many of the files you find on the web are
broken. Judicious use of something like Meshlab, or other tools
can repair them. Most users will not know that a file is not
manifold, since many slicers work around it. If the file is solid,
then I have found that all the features of openscad work with it,
difference/intersection/ whatever.
On 29/01/2025 05:09, Jordan Brown via Discuss wrote:
On 1/28/2025 3:13 PM, John Colagioia via Discuss wrote:
Hi, I'm new (but reading along for the last few days), so I
apologize if I violate some cultural norm or ask a question that
I'm supposed to know.
No worries, that's pretty rare. You might sometimes not *like*
the answers ("sorry, you need to understand how to write a
program" or "sorry, you need to learn high school math to work
effectively with trigonometry") but we're generally pretty good
about not taking offense.
That said, here's the short version: Might anybody know how to
use an object from another application (Makehuman
<http://www.makehumancommunity.org/>, in my case) in a way that
works more or less like OpenSCAD's native objects?
You're already on the right track with import(). import() is
more or less equivalent to polyhedron(), except that the data
comes from a file.
For example, if I export an STL file from Makehuman, I can
import() it into OpenSCAD, yes. However, if I apply an
intersection() or difference() operation to take just the head
or an arm, the surface-mesh aspect of STL files gets exposed,
with a gaping hole along the separation plane and parts of the
remaining surface looking see-through like what happens when
taking the difference between two native objects of similar sizes.
Mostly, OpenSCAD only works with solids.
If you're seeing gaping meshes, it suggests one of two things:
* What you gave it wasn't a valid mesh to begin with.
Unfortunately, OpenSCAD is pickier than a lot of other
consumers. It may also have issues with very small (~10^-6)
details.
* The previewer has trouble when the camera is inside the
model, notably including when it is inside invisible parts of
the model. A common issue is differencing away a large cube
and then having trouble when you position the camera inside
that invisible cube. Similarly, there can be issues if you
intersect with a large cube and then put the camera inside
*that* cube.
One simple check for whether OpenSCAD is unhappy with your mesh
is to attempt to union it with anything, typically a small cube,
and render.
import("myfile.stl");
cube();
then press F6 to render. If you end up with something that looks
like your mesh, you're golden. If you end up with nothing and
error messages in the OpenSCAD console, not so good.
If you supply a sample mesh, somebody can experiment with it a
bit. Some of us have tools for identifying problems... but I'm
not one of them.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
It took me forever to run some tests and revisit this, but I did want to
check back in to thank everyone for their thoughts on this. While I
haven't tried an actual print, yet, it looks like repairing the mesh -
FreeCAD's Evaluate & Repair Mesh tool, here; I've tried Blender's plugin
before, and it looks similar (but no Meshmixer on Linux) - PLUS the
convexity parameter comes pretty close for the default Makehuman model.
That's just bisecting (difference with a cube) the default model with no
proportions/identity elements set or accessories added, but good enough
for a proof of concept. The floating bits on the image's right, and the
white/transparent areas make me a /little/ suspicious, but they're now
tiny, localized spots instead of the entire model like that.
Again, thanks, everyone!
On 1/29/25 08:21, Roel Vanhout via Discuss wrote:
> If you don't want to use Meshmixer, I did have good experiences using
> Blender and the '3d printing' plugin which has tools to check for mesh
> manifoldness, as well as tools to fix issues automatically; the
> advantage of Blender is that you can manually fix things if the
> automatic procedures don't do what you want. But that is also the
> biggest danger of using Blender, sometimes I fall into a trap of
> making all sorts of manual adjustments that just make things worse
> and/or are a massive time waster.
>
> But you mentioned you already tried Blender - not sure if you used the
> '3d printing' plugin?
>
>
> On Wed, Jan 29, 2025 at 1:30 PM Raymond West via Discuss
> <discuss@lists.openscad.org> wrote:
>
> Exactly as Jordan stated. I've no experience of the make human
> files, but in general many of the files you find on the web are
> broken. Judicious use of something like Meshlab, or other tools
> can repair them. Most users will not know that a file is not
> manifold, since many slicers work around it. If the file is solid,
> then I have found that all the features of openscad work with it,
> difference/intersection/ whatever.
>
> On 29/01/2025 05:09, Jordan Brown via Discuss wrote:
>> On 1/28/2025 3:13 PM, John Colagioia via Discuss wrote:
>>>
>>> Hi, I'm new (but reading along for the last few days), so I
>>> apologize if I violate some cultural norm or ask a question that
>>> I'm supposed to know.
>>>
>>
>> No worries, that's pretty rare. You might sometimes not *like*
>> the answers ("sorry, you need to understand how to write a
>> program" or "sorry, you need to learn high school math to work
>> effectively with trigonometry") but we're generally pretty good
>> about not taking offense.
>>
>>> That said, here's the short version: Might anybody know how to
>>> use an object from another application (Makehuman
>>> <http://www.makehumancommunity.org/>, in my case) in a way that
>>> works more or less like OpenSCAD's native objects?
>>>
>>
>> You're already on the right track with import(). import() is
>> more or less equivalent to polyhedron(), except that the data
>> comes from a file.
>>
>>> For example, if I export an STL file from Makehuman, I can
>>> import() it into OpenSCAD, yes. However, if I apply an
>>> intersection() or difference() operation to take just the head
>>> or an arm, the surface-mesh aspect of STL files gets exposed,
>>> with a gaping hole along the separation plane and parts of the
>>> remaining surface looking see-through like what happens when
>>> taking the difference between two native objects of similar sizes.
>>>
>>
>> Mostly, OpenSCAD only works with solids.
>>
>> If you're seeing gaping meshes, it suggests one of two things:
>>
>> * What you gave it wasn't a valid mesh to begin with.
>> Unfortunately, OpenSCAD is pickier than a lot of other
>> consumers. It may also have issues with very small (~10^-6)
>> details.
>> * The previewer has trouble when the camera is inside the
>> model, notably including when it is inside invisible parts of
>> the model. A common issue is differencing away a large cube
>> and then having trouble when you position the camera inside
>> that invisible cube. Similarly, there can be issues if you
>> intersect with a large cube and then put the camera inside
>> *that* cube.
>>
>> One simple check for whether OpenSCAD is unhappy with your mesh
>> is to attempt to union it with anything, typically a small cube,
>> and render.
>>
>> import("myfile.stl");
>> cube();
>>
>> then press F6 to render. If you end up with something that looks
>> like your mesh, you're golden. If you end up with nothing and
>> error messages in the OpenSCAD console, not so good.
>>
>>
>> If you supply a sample mesh, somebody can experiment with it a
>> bit. Some of us have tools for identifying problems... but I'm
>> not one of them.
>>
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> To unsubscribe send an email todiscuss-leave@lists.openscad.org
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email todiscuss-leave@lists.openscad.org
JB
Jordan Brown
Sat, Feb 15, 2025 9:58 PM
On 2/15/2025 12:17 PM, John Colagioia via Discuss wrote:
That's just bisecting (difference with a cube) the default model with
no proportions/identity elements set or accessories added, but good
enough for a proof of concept. The floating bits on the image's
right, and the white/transparent areas make me a /little/ suspicious,
but they're now tiny, localized spots instead of the entire model like
that.
How big is the cube that you're subtracting? The obvious reason for
bits on the right side is that the cube isn't quite big enough.
Putting a # in front of the cube may make this more obvious.
On 2/15/2025 12:17 PM, John Colagioia via Discuss wrote:
>
> That's just bisecting (difference with a cube) the default model with
> no proportions/identity elements set or accessories added, but good
> enough for a proof of concept. The floating bits on the image's
> right, and the white/transparent areas make me a /little/ suspicious,
> but they're now tiny, localized spots instead of the entire model like
> that.
>
How big is the cube that you're subtracting? The obvious reason for
bits on the right side is that the cube isn't quite big enough.
Putting a # in front of the cube may make this more obvious.
JC
John Colagioia
Sun, Feb 16, 2025 1:38 PM
On 2/15/25 16:58, Jordan Brown wrote:
On 2/15/2025 12:17 PM, John Colagioia via Discuss wrote:
That's just bisecting (difference with a cube) the default model with
no proportions/identity elements set or accessories added, but good
enough for a proof of concept. The floating bits on the image's
right, and the white/transparent areas make me a /little/ suspicious,
but they're now tiny, localized spots instead of the entire model
like that.
How big is the cube that you're subtracting? The obvious reason for
bits on the right side is that the cube isn't quite big enough.
Putting a # in front of the cube may make this more obvious.
That's a neat trick! Much better than my usual debugging of reproducing
the intersecting objects. The cube is huge, though, and the bits just
float around well inside the boundaries. I still call it a success,
considering the mess that I had in the first iterations. Presumably,
the worst that'll happen is that the printer will eventually try to
dribble a couple of blobs in open space.
On 2/15/25 16:58, Jordan Brown wrote:
> On 2/15/2025 12:17 PM, John Colagioia via Discuss wrote:
>>
>> That's just bisecting (difference with a cube) the default model with
>> no proportions/identity elements set or accessories added, but good
>> enough for a proof of concept. The floating bits on the image's
>> right, and the white/transparent areas make me a /little/ suspicious,
>> but they're now tiny, localized spots instead of the entire model
>> like that.
>>
>
> How big is the cube that you're subtracting? The obvious reason for
> bits on the right side is that the cube isn't quite big enough.
>
> Putting a # in front of the cube may make this more obvious.
That's a neat trick! Much better than my usual debugging of reproducing
the intersecting objects. The cube is huge, though, and the bits just
float around well inside the boundaries. I still call it a success,
considering the mess that I had in the first iterations. Presumably,
the worst that'll happen is that the printer will eventually try to
dribble a couple of blobs in open space.