<Guest52>
I just wanted to make this longer without stretching it so that the site of the thread and the base of the model stays intact. The preview looks just fine.
<Guest52>
When I try to render the model, I get the warning "WARNING: No top level geometry to render"
<Guest52>
I also tried putting a union around the two parts but that doesn't change anything. Any help would be greatly appreciated. :-)
<Guest52>
*size not site
<drgerg>
Guest52: Try removing the semi-colon after "convexity=10)". If that doesn't do it, I don't know.
<dalias>
most likely rod.stl is non-manifold
<dalias>
semicolon is correct there. removing it will not work.
<drgerg>
OK. Thanks.
<Scopeuk>
hmm it seams to be happy enough to do Booleans on it
<dalias>
the preview doesn't actually do the boolean solid computations
<Scopeuk>
I know but if you comment the second import (leave the top module unmodified) that renders fine
<dalias>
it uses rendering hacks to just make it look like it did
<Scopeuk>
top does a boolean operation with the stl
<dalias>
yes it also doesn't do any solid computations then
<dalias>
it just copies the input polys to output
<dalias>
if they're not CSG'd
<Scopeuk>
I thought the CSG kicked in as soon as you performed a boolean operation
<Guest52>
Do you have any ideas on how to fix this without having access to the source model?
<dalias>
oh
<dalias>
try using a mesh fixing utility
<dalias>
meshlab, or whatever 3d editor comes with recent windows
<dalias>
or one of the online "fix my stl" services
<Scopeuk>
the windows viewer editor was happy with the stl unfortunately
<Guest52>
I already threw it into the prusa slicer. That usually reports any errors with the mesh but rod.stl seems to be ok
<dalias>
hm
<myosotis>
I've had some success with blender 3d-toolbox, idk anything about admesh, but 2 +1's is promising
<dTal>
Slicers are much more forgiving as a rule
<dalias>
yeah because slicers do most of the inside/outside computation in 2d slices not in 3d
<Guest52>
I just tried the two manifold repair filters in Meshlab. I didn't find anything to repair
<dalias>
:/
<Scopeuk>
Guest52, I was able to make the changes with 3d builder on windows (its not a scad solution but it gets you out of the whole) open the file, split the object (keep both halfs) translate the top up 20mm, extrude the top down 21mm, merge object export http://scopeuk.mypicture.info/rod.3mf
<Scopeuk>
dalias and dTal are quite right openscad normally only complains when there is some issue with the stl
<Scopeuk>
in this case it appears to be incredibly high poly so I wonder if the grid snapping has caused degenerate triangles
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<InPhase>
Guest52: Actually, the slicers almost never report non-manifold errors. They are written to be very tolerant
<dalias>
scopeuk, if that's the case, meshlab simplification could help
<InPhase>
Guest52: But doing computational geometry is a trickier undertaking with stricter requirements.
<dalias>
i use quadratic edge collapse decimation on most high-res meshes i get from other sources
<dalias>
just because otherwise they're impractical to work with
<dalias>
and the excess resolution has no usefulness
<InPhase>
Guest52: That
<Scopeuk>
14.3k faces on the base stl
<InPhase>
Guest52: That rod is however not particularly difficult to just make in OpenSCAD. It would be less work than trying to repair a defective stl.
<InPhase>
Guest52: The threads you can do with this: https://github.com/rcolyer/threads-scad The rest of the object is basically just a rotate_extrude of the 2D radial outline, and then you difference that cylindrical hole into the top middle.
<myosotis>
i'm a huge noob, and yeah, that rod should be rather easy to reproduce. the threads might not be 100% like they are, but probably close enough
<Guest52>
Simplification did the trick thank you dalias, and, of course, also thanks to everybody else :-D
<InPhase>
Guest52: A simplification option in meshlab?
<Guest52>
yes
<InPhase>
Well, amazing. 9 out of 10 attempts to repair with meshlab seem to fail. :)
<Guest52>
quadratic edge collapse decimation with standard settings
<dalias>
that one works really well for me
<dalias>
i typically reduce organic-shaped models from like 40-100 MB down to 1-5 MB
<dalias>
which makes it practical to do any printability tweaking or to import them for CSG in openscad
<Scopeuk>
in this case they just appear to have gone for "very round circles" combine that with the thread and it gets really tight nit
<Guest52>
So, just for my education: The problem was, that there were way too many faces for openscad to render?
Guest52 has quit [Quit: Client closed]
Guest52 has joined #openscad
<Guest52>
Limiting the faces doesn't seem to be the only problem, because, if i try to limit the number of faces this way:
<Guest52>
WARNING: No top level geometry to render
<Guest52>
again
<Scopeuk>
as far as I'm aware $fn has no effect on an import
<Scopeuk>
import faithfully represents the faces within the imported model
<Scopeuk>
I believe but can't confirm that the issue is very small triangles being snapped to openscads internal grid before the final union is causing some invalid triangle shapes
<Guest52>
so there basically is a lower limit on how small a triangle can be in openscad?
<Scopeuk>
I can't remember the exact details of how the grid works to know if its an absolute limit or relative limit. I'm not familiar with that bit of the engine
<Guest52>
Ah: "SVG import support forr $fn is still in the develop builds"
<Scopeuk>
that also only applies for SVG and in this case we were importing an STL
<Guest52>
Could it be that that's the same for STL Files?
<Scopeuk>
as far as I'm aware there is no support (development or otherwise) for remeshing 3d models
califax- has joined #openscad
califax has quit [Ping timeout: 240 seconds]
califax- is now known as califax
<Guest52>
hmm... that sure would be a handy feature to have :-)
<Guest52>
Anyway. Thank you all for your help.
J2270 has quit [Quit: Client closed]
J2270 has joined #openscad
califax has quit [Ping timeout: 240 seconds]
califax has joined #openscad
Guest52 has quit [Quit: Client closed]
califax has quit [Remote host closed the connection]
califax has joined #openscad
<InPhase>
I think we need to re-evaluate this grid snapping with the fastcsg work.
<InPhase>
If benchmarking shows it is no longer giving meaningful gains, it should probably be purged, or at least reduced to an option defaulting to off. It sure does contribute to a lot of problems.
<dalias>
what is the grid snapping and what it is for?
<J2270>
why care about a grid .. but if two points are less than 1fm apart - they should have the same coordinates
<myosotis>
idk, maybe it has to do with input sanitization, or floating point precision
<myosotis>
if you snap all the points to a known grid, then all of those issues magically disappear, while introducing a new set of issues I imagine.
<dalias>
j2270, except sometimes you get a stupid STL file that's mathematically manifold but with spurious detail at 1 fm scale, that becomes non-manifold when you collapse those points
Joel has joined #openscad
arebil has joined #openscad
<buZz>
J2270: what does 1fm mean?
<dalias>
femtometer
<buZz>
huh, how is that relevant, openscad doesnt have sizes/units
<buZz>
'1' can be 1 kilometer
<dTal>
openscad doesn't, but the wider ecosystem has settled on a loose convention of 1 = 1mm
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<dalias>
here 1fm = 10^-12 * 1 openscad unit
<myosotis>
even if the units are relative, you still have distance between them, and that distance affects precision for sure
<dalias>
but the point was not the exact size anyway just "ridiculously small detail"
<buZz>
ah ok
<myosotis>
if I have a feature that's 10^100 long, and one that's 10^-100 long, the system has to deal with both of those scales, and I suspect that it's not a trivial problem to deal with
<teepee>
fast-csg is trying to cover that issue by remeshing
<teepee>
the problem is not so much there are those vertices close together but that some of the algorithms are like O^3 so the number if really really critical
<dalias>
:)
<dalias>
i wish tools weren't so bad about exporting STLs with excess resolution
<dalias>
it's like audiophile brainworms
<teepee>
plus we should move on to saner file formats which does not solve the issue but helps with problems caused by it
* teepee
points to J2270 :)
<buZz>
^_^
<dalias>
no attention to the actual information content and choosing resolution appropriate to represent it, just throwing huge numbers and huge storage at the problem for solid-gold-digital-audio-cable reasons
* dTal
keeps his music collection entirely in FLAC where possible
<teepee>
that too, and OpenSCAD is partially guilty by giving people a flat-shading look at their designs
<myosotis>
idk how much openscad can be expected to be a perfect fidelity rendering engine... that seems like another concern entirely
<teepee>
it probably does not need to, but some slightly better display might prevent people from always slapping $fn=200 at the top for display reasons
<teepee>
even good old phong would likely help
snaked has joined #openscad
<dalias>
well near 200 is needed for some things
<myosotis>
be careful of scope creep I guess. modularity often seems like a good idea. sometimes it is
<dalias>
but the problem is ppl use $fn because they dont understand $fs and $fa
<dTal>
I don't think you should try to hide the resolution
<dalias>
$fa=1.8 $fn=0.25 or so will give similar results without 3mm holes having 200 0.05mm segments
<dTal>
rendering techniques that smooth polygons are designed to mislead about the underlying geometry
<teepee>
agreed, it should still be possible to select flat shading, it's useful
<myosotis>
Does openscad come with a demo or getting started file? something like blenders "default scene"...
<teepee>
but a more reasonable default + better default display might go a long way
<dalias>
default $fs is so bad
<dalias>
$fa is borderline ok
<teepee>
myosotis: it comes with examples and a welcome screen
<teepee>
the blender default cube is actually annoying ;-)
<dalias>
$fs=2 (default) is just unusably bad
<myosotis>
yeah, for anybody that knows how to use blender, it's barely an inconvenience
<knielsen>
teepee: that's great, maybe I can use some of Easter to get a new version uploaded
<myosotis>
but if you're new, it sends you down a path of discovery
<teepee>
even I know the 2 key presses to delete it
<dTal>
controversial opinion, a function named sphere() should not, by default, return something appreciably more angular than a dodecahedron
<teepee>
knielsen: nice, there's a build issue I'm seeing for flatpak builds, missing header file for using size_t, I'll send Florian a reply, maybe we can even get a fixed 1.5.1 :)
<teepee>
otherwise, check the flathub repo for the patch
<knielsen>
cool, thanks
<dalias>
I dont know if it's reasonable to fix now, but IMO global $fs/$fa/$fn should never have resulted in effective $fn smaller than 10 or so.
<dalias>
only explicit $fn=3 or whatever should have done that
<myosotis>
just to give you an idea, I've build maybe 20 or so models in openscad, probably printed 10 or 15 of those, and had no idea about any of the special vars other than $fn, or that there are so many useful libs built in
<dalias>
:)
<teepee>
heh, same here :)
<J2270>
wonder why the jason file contain "nozzle": "0.40000000000000002", when the value was 0.4
<dalias>
i've started using $fa=5; $fs=.3 with pretty good results
<teepee>
well, it's all about documentation :)
<myosotis>
I keep hearing variations of "need to provide better learning paths" and I can attest that it would be helpful.
<dalias>
j2270, :)
<dalias>
because there is no double 0.4
<teepee>
J2270: probably 0.4 is also not possible to represent, same as 0.2
<dalias>
but i dont know why someone would represent is at that which is also not exact
<dalias>
if you're rounding it, it should round to 0.4
<dalias>
if not, it should end in a 5
<peeps[zen]>
dTal: tbf a default "unit" sphere (in de-facto mm unit) is really small though
<InPhase>
4/10 is 2/5 which is not a divisor with prime factors of 2.
<dalias>
peeps, 1 mm is not all that small. if it's a 1 mm cylindrical hole, that's perfectly reasonable to appear in a practical model for 3dp use
<J2270>
wait what why are 0.2 and 0.4 such bad values
<teepee>
myosotis: people have actually found the tutorial and tweeted new and more complex cars every couple of days :P
<teepee>
J2270: because floating point does not speak base 10 as humans do
<J2270>
but 2× 0.1 would work?
<dalias>
j2270, no
<dalias>
the smallest multiple of 0.1 that's exactly representable is 5 * 0.1 = 0.5
<teepee>
hmm, does the bot know?
<dalias>
0.1 = 0.5 / 5, and 1/5 is a repeating binary fraction
<teepee>
floating point?
<teepee>
floatingpoint?
<myosotis>
yeah I think the docs problem is related to the userbase size. I'm not sure there's much to do about it.... I like houdini's task-based learning path organization, and I think blenders open movie efforts were incredibly helpful for that project
<InPhase>
J2270: It must be n/2^m for integer values n and m to be exactly representable.
<J2270>
makes me uncomfortable ..
<InPhase>
J2270: For example, 3602879701896397/2**53 is 3602879701896397/9007199254740992 which gives you that 0.40000000000000002
<J2270>
so i buy 0.25 nozzles ?
<teepee>
if you are a patient person, yeah
<teepee>
I'd like a 1.2 nozzle :)
<myosotis>
I always normalize my numbers to integers if the application allows it. fp math makes my code sad.
<teepee>
I think with the cool models you did, you probably can do cool stuff with a 0.25 nozzle
<J2270>
with the 0.2 nozzle i can print 0.6 ( just not at 0.2 layer height)
<J2270>
bigger nozzles cause terrible stringing with petg
<InPhase>
J2270: You can store your nozzle units in microns if it makes you happier.
<InPhase>
400um nozzle
<InPhase>
That gives it all those factors of 5 it needs to work with. This will work as long as we don't switch from base-10-SI to binary-SI.
<InPhase>
Or hex-SI which would be another very reasonable choice.
<J2270>
Ü yeah just lets assume all units are in μm and get rid of floating points .. at least under 1nm things get blurry
<InPhase>
Even with superresolution.
<J2270>
with current setting 3mf doesn't store below 10-⁶
<Scopeuk>
Floating point is a lot of complexity but when your dealing with a whole load of things of similar but unknown magnitude it's a solid solution, for known magnitude there is fixed point, I guess if fraction reprentation issues are a problem grab one of the old IBM power pc's for financial services with base 10 floating point
<Scopeuk>
Only in their mainframes that I know of, standardised in ieee754-2008(754r)
fling has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
fling has joined #openscad
<Virindi>
modern languages have base 10 floating point also, for example in .net it is System.Decimal
<Virindi>
it is sold as a good type for holding currency values.
<Scopeuk>
Same standard just implemented software side I would wager
<Virindi>
96-bit integer, 7 bit exponent
<joseph_>
Hello, I have a question about Google Summer of Code. I tried posting in the mailing list last night but it doesn't seem to have worked.
osfesa has joined #openscad
<J2270>
teepee Inphase didn't you participate GSC?
<J2270>
ah yes last month GSoC is a go this year
<J2270>
so joseph_ what is the question - i am sure so will RSVP soon
fling has quit [Ping timeout: 240 seconds]
fling has joined #openscad
<InPhase>
joseph_: Hi Joseph. And yeah, what's the question?
<InPhase>
Virindi: Decimal floating types are often sold for this, but it's also a terrible idea.
<teepee>
yep, perfect time for gsoc questions, IIRC deadline is April 19th
<InPhase>
Virindi: System.Decimal for example picks up rounding errors after the 15th digit, which is basically the same as what double does.
<teepee>
osfesa: hi, that's the name from the "collapse all" github discussion?
<InPhase>
teepee: I feel like I forgot to do something about GSoC in the midst of a work crunch. We had talked about some part 2 of one of the projects, and I suggested I could write it up, and then I don't think I ever wrote anything...
<teepee>
no problem, the 1 part it there and if anyone is interested, we can always discuss extended topics
<InPhase>
I guess. :)
<osfesa>
teepee Yes, I was waiting for t-paul.
<osfesa>
I've got my change submitted on my fork, but it is not the head of git (forked on a broken change). I've never used git before, so I'm a bit lost
<InPhase>
I guess I should also dig through the logs and remind myself what that was.
<teepee>
osfesa: that's me, I'm never able to get the nick names across systems :)
<teepee>
osfesa: no worries, I've seen that there's some extra stuff in there from a missing update or something, we can go through this
<teepee>
happened to me yesterday too, so using git for long time does not save anyone from making mistakes, luckily it pretty much always fixable
<InPhase>
osfesa: Here's a secret if you've really really screwed up git... Clone a new copy, manually copy the files you've updated over, run "git diff" to make sure your changes are correct, and then add and commit again.
<osfesa>
Any guidance on how can I create a branch under the openscad repo so I can do the pull request or, I'll try to do it from my fork, although I haven't found the way
<InPhase>
osfesa: The classic way is to fork to your github page, and push the changes to a new branch there.
<InPhase>
osfesa: So you click to fork a copy to your github page, clone that out, create a new local branch, add/commit your changes, push those back to a matching branch on your fork, then go to the openscad page on github and it will suggest making a PR from the new branch on your personal page.
<teepee>
it's probably not too many changes? so maybe stashing those locally and re-cloning the repo on github side and then also locally is probably the quickest solution
<InPhase>
osfesa: And if you need instructions for any of the steps in between all those commas, just ask.
<myosotis>
I'd first checkout a new branch based on my current one (so I have a backup branch of my changes) then I'd try a "git rebase" on the right branch. If that turned out to be a pain, I'd see if my changes are easy enough to reproduce on the correct branch
<teepee>
yep, key is the "create a branch" as that will separate things better, the pull request then will be the action to combine everything into our upstream repo (the openscad user/project on github)
<myosotis>
if git rebase works, it's the easiest / cleanest solution to change your branch starting point. It often does not though.
<teepee>
lets not introduce people to git rebase as first command :)
<teepee>
it's hugely useful and powerful, but not the thing to look at first
<InPhase>
After more than a decade of git, I hate git rebase, and go to great lengths to avoid it.
<myosotis>
maybe I'm just too optimistic
<myosotis>
when it works, it's a beautiful thing
<InPhase>
myosotis: Which is not something I like to say about my tools. ;)
<myosotis>
but that's why I start out with a new branch, things often go horribly wrong and you get trapped in merge hell
<Scopeuk>
version control 101, in your own repository commit anything that works so you can roll back. when you commit say what you did (short form) and why you did it
<Scopeuk>
almost everything else is just syntax
<osfesa>
How can I create a new branch from your repo and be able to do a pull request if "my branch" is not on Github?
<myosotis>
ofsea what vcs are you familiar with, if any?
<InPhase>
myosotis: I've done comparisons where git rebase gives merge by a thousand papercuts, but a simple merge just completes automatically.
<myosotis>
I've lost changes too many times doing simple merge in the same situation though. you pick your poison
<joseph_>
InPhase: Thanks for your response, I just got back from lunch. I'd like to apply to contribute to OpenSCAD through GSoC this summer. I know I need to send an application on Google's official site, but what is involved from your end?
<myosotis>
osfesa, you could add their repo as a "remote" and then simply checkout the branch you want.
<teepee>
joseph_: discussing things and posting draft versions will very likely increase chances of a proposal that will be accepted
<teepee>
how you do that is up to you, google does not provide the integrated google docs anymore this year, only the "update PDF files till deadline"
<InPhase>
joseph_: That would involve discussing with us what project you're interested in, and getting to know us a bit, and us you, so that we can see if you can get a good understanding of what would be involved with the work and have a good chance at completing it. Some discussion about details of the plan is helpful, and demonstrating you can go through steps like by submitting a very tiny patch to
<InPhase>
something could help.
<osfesa>
myosotis In my company, we use Perforce. On Git I've done the basics, but never a pull request on Github.
<InPhase>
joseph_: At the end of the day it's the OpenSCAD mentors who select from the applicants to our project. We're generally looking for ability to complete the work, and good ability to communicate about technical information, as that has historically been a very important part of successful projects.
<joseph_>
teepee InPhase: Thank you. Here's a bit about me. I have not contributed code to OpenSCAD before, but I'm experienced with it from the user side. I'm currently a Master's student in computer science at UMass Amherst, with an unofficial focus on graphics and systems. I'm about to be in class but when that's done I will start looking at the GitHub issues that have GSoC labels. Are there some that you think would make especially good
<joseph_>
project proposals? Also, do you have suggestions for a good "first issue" that I could try patching?
<myosotis>
ohhhh okay, git is fundamentally different than something like subversion or perforce. with git. There is no "main" repository. every repo is just as valid as every other one.
<Scopeuk>
osfesa unless you have objections to working on git hub (no judgement that's a personal choice) I would probably recommend creating a fork on git hub of openscad (which will give you your own open scad repository) and setting up github to let you work with that repository from your development machine
<Scopeuk>
git hub to git hub pull requests are the "normal" and well supported path
<teepee>
joseph_: sounds great, the label is called "low hanging" ... (fruit), but we can have a look if there's something specifically fitting
<myosotis>
so osfesa: while you're used to there being one central source of truth that must be pushed to... git has no such restrictions. as long as they are based on the same repo, any git repo and push / pull to any other git repo (as long as there's network connectivity between the two)
<InPhase>
joseph_: Sounds like a promising educational background for it. As someone who has advised a lot of people, I would say personal passion is particularly important for work like this, so I would say first go through the list and see which ones are particularly exciting to you as topic areas. They are more guidelines than recipes, and the exact details of how to do them are open to discussion and some
<InPhase>
change. It's just healthy to have that discussion here first, so that we can make sure everything aligns with long term project goals, and unmentioned problems that might be lurking in the code base.
<myosotis>
s/and/can/
<InPhase>
joseph_: We can talk later. I'm in your timezone (PA, I work at UPenn), and teepee is +6 hours in Germany, but aside from sleeping once in a while, we're around pretty often.
<teepee>
and if not around, we have a log (see topic) and a bot always happy to deliver messages :)
<InPhase>
joseph_: As you review the projects, note that GSoC has a half and a full sized program option this year, and there are projects marked long and medium. But what I was just discussing with teepee is that some of the medium projects have longer options that we didn't write out. So there is probably not a need to filter by the length if you're interested in the full program length.
<pa>
happy to read there's motivated dev interest in the graphics part of openscad :-)
<pa>
i did look into that part before, and the code seemed pretty entangled and with some refactoring overdue :-)
<teepee>
a project that does not need refactoring is either dead or not used :)
<myosotis>
or is mission critical, and "works" already :)
<InPhase>
Regrets per line would be an interesting code evaluation metric.
<myosotis>
wouldn't that just measure the age of the project?
<Scopeuk>
InPhase as software developers we're not ready for that
<myosotis>
or the development of the developer
<InPhase>
The age of the project divided by the experience of the programmers minus the wisedom of the managers/leads.
<teepee>
myosotis: if it's mission critical and "works" that just means people are too scared to change it so the management needs to be swapped out for people who know what they are doing ;-)
<InPhase>
s/wisedom/wisdom/
<Scopeuk>
teepee to an extent, there is also "acceptable risk" i.e. there is more risk of inducing a more serious defect through modification that the risk posed by the know existing defect
<myosotis>
I think there's some value to not touching stuff that isn't broken in some cases... I don't think openscad is keeping people in space alive or anything though
<InPhase>
Yet.
<Scopeuk>
anyone found to be animating guidence systems with openscads animation system needs help
<teepee>
yeah, partially true, but also still partially a dangerous interpretation, see those 2 boing crashes not long ago
<Scopeuk>
thats was a bigger institutional failure
<Scopeuk>
increasing the control authority of a system without revisting its safety case is jsut pure stupidity
<teepee>
yeah, and it's certainly a difficult topic and in that case not so much a dev issue
<teepee>
just one extreme side of the general topic
<Scopeuk>
yep that has to be cultural, there isent an avionics supplier on the plannet that doesent have that in their systems requirements capture proccess
<myosotis>
am I good at derailing conversations? or are you guys just easily distracted...
<Scopeuk>
we're definately easily distracted
<teepee>
if I want to do stuff without distraction, I could just continue working, so yes, distraction good (within reason of course :-)
<osfesa>
I just updated my fork. the changes are in "my master" branch. Shall I do the pull request from my repo to the openscad repo, or the other way around?
<osfesa>
None of them offers me the way to see the other repo
<InPhase>
I'm pretty sure you want your 3D printed habitat to be a manifold model.
<Scopeuk>
osfesa you create the pull request from your repo
<InPhase>
osfesa: Both pages will suggest the pull request.
<Scopeuk>
it is a request for openscad to pull from you
<InPhase>
(Last I checked.)
<InPhase>
osfesa: You can just go ahead and click. It won't do it until you see what it's trying to do and confirm it. It will say things like "request to merge changes from osfesa/openscad/somebranch to openscad/openscad/master"