nedko has quit [Remote host closed the connection]
nedko has joined #openscad
myosotis has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<Cepeu>
I need help for a question for which I did not yet find a solution in google yet. I would like to use an external editor. My setup is working and on a save/change of the editor file Openscad GUI previews my object. I would like to see my object rendered though (like pressing F6). I figured out I can use render() as a function in the openscad code.
<Cepeu>
This works but it would be easier if I would not need to explicitly use the function in code. Another alternative might be to do an STL export and call an external STL rendering program but both seems like a workaround. I found the command line argument --render arg but so far no dokumentation what arg supposed to be.
<myosotis>
I use an openscad Visual Studio Code plugin
<Cepeu>
Yes I use the same setup but it only does an F5 preview
<myosotis>
it gives me an F5 shortcut to open the edited file in openscad, and automatically refreshes that preview when I save the file in vscode.
<myosotis>
yeah, I have to go to openscad and hit F6 when I want a render. idk a way around that :(
<myosotis>
You can call openscad from the cli.... I wonder if you can setup some sort of on-save trigger to produce an stl or jpg somewhere
<Cepeu>
Exaactly that ist my problem;) it seems quite akward to do it that way if F5 works allready
<Cepeu>
And now it will be rendered like if I pressed F6. But I do not want to do that for every difference or union ....
<myosotis>
not trying to be contrary... but do you really need to see the render while you're editing? why isn't preview good enough?
<Cepeu>
Probably because I am a mediocre programmer and want to often see what the output is. The F5 gives me hidden/occluded views.
<Cepeu>
For the above example the "objects" which are to be subtracted can still be seen and that is irritating sometimes
<myosotis>
okay... I might use inotify to watch my edited files, and then run a script to close openscad (if needed) and re-open it and render.
<Cepeu>
I am using a window system. But how do you call openscad to open a file and render it? Even if you do not use the build in watch function?
<Cepeu>
That actually would have been my second approach. Use Visual Studio Code and export an STL with each save. Then use an STL viewer to open up the STL .. still kind of akward
<myosotis>
I think you might have to specify an output format to make it render
<myosotis>
but it looks like it supports png and other raster graphics, so maybe you can render to a pic and keep a viewer open that automatically refreshes
<Scopeuk>
openscad model.scad -o mymodel.stl would generate the stl directly
<Scopeuk>
generally though working with the preview is your best option for development
<myosotis>
<Cepeu> Probably because I am a mediocre programmer and want to often see what the output is. The F5 gives me hidden/occluded views.
<Scopeuk>
if you have differences resulting in the occluded faces add the over run needed to get it to show cleanly
<myosotis>
if I have a 1m thick wall, and I difference a 1m thick cutout, then f5 will show a blurry crappy view there
<Cepeu>
Yes the benefit of the Openscad GUI ist that I am used to it, it tracks error and I can even use the paramtrizier easily if I want. The main benefit of render F6 is that I can take a look at my object.
<myosotis>
but if I cutout like a 1.1m thick section, that extends farther than I need, the f5 preview will be clean
<myosotis>
that's the only trick I've ever needed to make the preview look like the render personally
<Scopeuk>
its a maths problem, if your cut and your start shape are the same thickness you create an object with zero width at either side, extending the cut beyond the edges resolves that issue
<Cepeu>
@Scopeuk Ok yes maybe the overun is one way to solve part of the problem.
<Cepeu>
@Scopeuk I am not sure it will help all the time but you are right in that regard that it is a boundary problem
<Scopeuk>
it generally solves most of the "rendering issues" that people encounter. its probably good enough to make your standard workflow update observe preview and then just f6 once in a while for specific situations or before export
<myosotis>
yeah, personally I think getting in the habit of doing it this way is a much better approach than setting up a constant render
<myosotis>
but if you don't want to, I think a hacky inotify or ide on-save trigger to produce a rendered raster or stl file that's loaded into a viewer smart enough to auto-refresh is your next best bet?
<Cepeu>
Well if you place an object by translate you need to factor in to place it center and make it a bit bigger - so it complicates things. Also most of my projects are not as big as that Rendering will really hurt me.
<Cepeu>
myosotis Yes it seems the only other working approach would be to generate an STL, check if the STL has changed and call an external STL render program
<Cepeu>
Ok I now need to find a simple and fast STL render program for Windows ;). But there seems to be no simple solution so that helped. Also to remind me that I can use overbound to alleviate the problem. Thank you both!
<J22>
3mf not stl Ü
<J22>
still don't understand why preview is different to the render (except z fighting)
<myosotis>
render is slow, preview cheats.
<J22>
yes sure - WASM has no preview as far as i understand this and uses an stl viewer to display
<myosotis>
yeah, the original demo produced an stl file for dl. the current cloud version has a third party stl viewer (that doesn't handle browser sizes well)
<J22>
but the preview was always sufficient for me - so i never had a render that "surprised" me
<myosotis>
me either. like scope was saying, I just overfit my parts in the necessary dimension to make my preview look clean
<myosotis>
I save all my parts as modules() in code, so it's pretty trivial to scale it in the direction I need
<J22>
although i had lately a difference that had so small walls that they where not displayed - but a hull showed them until the overlap was bigger 0.0001 something
<J22>
but for printing those are ignored anyway
<J22>
( i even started to add sub printable geometry to have "meta" data (as SCAD has no dialoge to edit 3mf meta data) or a circular outline for infill.
StudentWeis has joined #openscad
<Cepeu>
J22 Is 3mf more "detailed" that STL or easier to import into other CAD programs?
StudentWeis has quit [Client Quit]
<J22>
stl is from the 80s 3mf is smaller (shorter loading times) and add more features (that are not used by SCAD Ü )
<J22>
also 3mf has a unit so it is not arbitrary like stl
StudentWeis has joined #openscad
StudentWeis has quit [Client Quit]
<Cepeu>
J22 Hmm I will take a look. Load times should not be a problem for the file sizes I am working with and SSD beeing a standard setup. But unit information is definitv a benefit
<J22>
it also can hold color and meta data .. a thumbnail , images mappings etc. but that cant be done with SCAD
<J22>
slicer store printsettings in 3mf too - also heard that this can cause problems in some slicer when you have different multi material setup
<J22>
however 3mf is just an more up to date format
arebil has joined #openscad
<Cepeu>
J22 Yes. I took a look. Storing the printer settings looks like a big benefit also. I have not yet found the time to build a printer on my own much less to enhance the build for a dual extrude ;)
<J22>
i like that my 30-80mb stl are now 3-8mb as 3mf Ü
<Cepeu>
J22 the amount of viewers for 3mf seems to be a bit limited for windows. Found only 4 so far. Well the most complex I did was a something like a recursive walking algorithm kind of a turtle algorithm. Never scratched more than 1-2 MB STL files I think
<J22>
windows has build in viewer ( and sure they are buggy as helll wenn saving 3mf)
<J22>
when windows tried to add all that 3d printing support they used 3mf
<Cepeu>
J22 Hmm then again I just checked one of my more simple designes with 3 Objects of the same kind was 14MB so the project I made the turtle algorithm for could become quite large it seems
<J22>
the bigger stl files came when you use round edges as the point count explodes
<Cepeu>
J22 Aha ok good to know that it comes from the amount of points
<J22>
just had a Easter egg with 23mb that went to 1.8mb as 3mf
<Cepeu>
J22 Yes it seems that my big STL are mainly due to a high $fn number
<J22>
cepeu you can use $fa and $fs to have that dynamically to avoid small details with to many fragments
<J22>
cepeu depends on the size you print ..
<Cepeu>
J22 Well egg sized to hang it beside an egg ;)
<J22>
40mm about 2h
<J22>
äh 1h
<J22>
40cm filament
<J22>
4cm heigh
<J22>
ups 80cm fiament .. more 2h (0.2 nozzle)
<Cepeu>
J22 Looks nice for sure. I will finish the refirgerator upgrade for my wife and maybe I will take a look where to find such an esteregg to print for easter then
<J22>
while cura centers stl .. 3mf are placed as they were saved (which is nice but a centered egg is cut in half if not moved )
<Cepeu>
Aha ok good to know - but you can center/move it in cura and resave it with the printer settings I assume?
<Cepeu>
J22 you also did a star ;)
<J22>
yes sure .. the nice thing is you can have like inlays that are placed where they should be (without merge )
<Cepeu>
J22 Because 3mf will store the inlay as seperate object?
<J22>
i think also stl can have multiple objects , in 3mf you can have groups of objects and multiple - scad can save multiple objects when lazy union is used at top level
TheAssassin has quit [Remote host closed the connection]
<J22>
but i meant that i can make object A and Object B in 2 3mf files and they are placed how i saved them
TheAssassin has joined #openscad
<Cepeu>
J22 ah ok I see. So I could easily make OBJ1 .. OBJn (of the same kind but placed differently) and load as many 3mf files as I want to print for example
<J22>
yes you can - so e.g. when i load a 3mf file with 3 cylinder as 3 objects then the slicer will center the infill for each -
<J22>
but when you have like a cube with text you can save the cube and the text in two files .. and when printing the cube .. and with different filament the text .. they come together as defined SCAD
<J22>
but you need to save them at [100,100,0] so they are on the print bed as [0,0,0] is the corner ( some printer have 0.0.0 at center not sure how that affects the slicer positioning objects)
arebil has quit [Read error: Connection reset by peer]
<Cepeu>
J22 Ok thank you for your input. I need to run - but I will keep 3mf in mind and do some experimenting :). Thanks again!
<J22>
cheers
arebil has joined #openscad
myosotis has quit [Quit: myosotis]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
Cepeu has quit [Quit: Client closed]
<joseph_>
teepee InPhase: I'm interested in https://github.com/opencax/GSoC/issues/55 and I also like how it has the potential to be combined with #56. I took a look at the low-hanging issues and #3706 caught my eye. Let me know if there's one that would be better for me to start on.
<InPhase>
Oh, we still have #3706 open. Yeah, that's probably simple enough.
<InPhase>
joseph_: And I figured you might bite on 55 + 56 given your declared interests.
<joseph_>
I'm also happy to set up a time to discuss the project possibilities in greater depth. This could be before or after I've started drafting a preliminary proposal. Thursdays generally are my most flexible day, although it's likely I could set aside a block of time tomorrow as well
<InPhase>
peeps[zen]: You around? joseph_ is contemplating submitting a GSoC with "Improve GPU Shader" as part 1. I remember you had some thoughts on that one.
<teepee>
as for the shader topic, I suppose that's pretty flexible, both by combining with #56 or even something else
<peeps[zen]>
InPhase, joseph_ currently, shaders are only really used when show edges is enabled
<peeps[zen]>
there is an ongoing issue, when edges are enabled that faces sometimes randomly get "black hole" artifacts, depending on the exact viewpoint
<InPhase>
peeps[zen]: Whatever happened with those experiments with shader axes and lighting support for surfaces? Was that just local experimenting or did anything make it to a PR?
<peeps[zen]>
InPhase: yeah the shader axes were local experiments as shadertoy type of things, not integrated with OpenSCAD
<InPhase>
Ok.
<peeps[zen]>
so, i see the holes in the faces as kind of a big problem for shaders, which I *think* is because OpenCSG uses the old style fixed pipeline GL calls to generate the z-buffer
<peeps[zen]>
then the shader transformation presumably has slight mismatch in depth calculations (it has to be exact match since OpenCSG relies on gldepth GL_EQUAL for its trickery )
<J22>
inPhase glossiness?
<peeps[zen]>
specular lighting, yeah
<InPhase>
J22: Yeah, specular. The core difference is discernible on the cube surface. Stock OpenSCAD has all cube surfaces one color across the surface.
<J22>
didn't the other renderer switched to physical lighting?
<J22>
(sure you would need materials for that)
<InPhase>
peeps[zen]: Were those specular lighting experiments done as quick manual-edit hacks, or was there some usable code in there?
<peeps[zen]>
i can't even remember, i'd have go back and review what I was doing there. but i think the sample image has no nasty artifacts only because there's no CSG happening there
<peeps[zen]>
...i'm starting to remember it was a bit of a hack since it was still tied to having "show edges" enabled
<peeps[zen]>
even though that shader sample was not actually showing them
<InPhase>
I think you might have color-matched them or something. I vaguely remember some rambling about that.
<InPhase>
And my mental response was "whatever, that looks great". :)
<peeps[zen]>
color matched? iirc you asked me to make the screenshot with a custom color scheme of yours?
<InPhase>
Perhaps the shader tweaks themselves at least could be salvaged as an example to use for custom shaders.
<InPhase>
If you still have those files lurking somewhere.
<InPhase>
I suppose that wasn't peaked out in optimal appearance. The sphere is a little oversaturated. But it's in a really good starting direction.
<peeps[zen]>
yeah, i have like 32 openscad_[xxx] clone dirs for various unfinished things. i'm sure they're around somewhere... i gotta run some errands, but i'll try to dig it up later
<peeps[zen]>
anyways, the whole point I was getting at re those artifacts: if we ever want to get rid of those them for shaders in general, then I think OpenCSG needs to be rewritten to be shader based, so the fragment transformations are consistent between opencsg and us
<teepee>
but we can start with the F6 render, I hope?
myosotis has joined #openscad
<Virindi>
ooh, I can't wait for the day when preview is better than flat-shaded :)
<teepee>
as discussed above that's likely much more difficult
<teepee>
yeah, some actual export to render-engine would be nice
<Virindi>
you'd have to export each object in an assembly separately to do that, what a pain in the butt. only useful if you are doing something like a pretty render for a client
<teepee>
at some point it sounded like yafaray might be a good candidate
<J22>
with lazy Union those objects stay separate so if we would have some "group" export this would be half way to multi material and render
<Virindi>
maybe openscad should have some concept of top level objects. each node in the top level implicit union is a separate object, if you export you get several
<Virindi>
heh
<Virindi>
good idea :P
<J22>
Ü
<Virindi>
although
<Virindi>
I like having modules which render a bunch of different parts. For example, bolts and bearings and then calls to modules for project-specific parts
<Virindi>
it would be nice in that case to have a way to keep them separate even though they are inside a module
<J22>
yes like color() .. you would have group(ID) and everything with the same ID gets one object .. also for 2D
<Virindi>
perhaps just by omitting the explicit union
<Virindi>
sure, that would work
<myosotis>
using parameters would make it nice on the frontend, but a lot of work on the backend to get it setup right with all the cases
<Virindi>
in ancient times with povray (which I consider basically the same as openscad) we used to have scripts which set parameters in the code which caused each thing to be rendered in turn (for masking, or for video sequences)
<Virindi>
so you would have a bash script which repeatedly called povray and set a code variable to a different value
<Virindi>
I suppose that would be viable even now, just clunky
<J22>
virindi you can already activate lazy union in the nightly build
othx has quit [Remote host closed the connection]
osfesa has joined #openscad
othx has joined #openscad
othx has quit [Remote host closed the connection]
othx has joined #openscad
<J22>
myosotis probably also the reason why exporting colors in 3mf is not trivial
<osfesa>
Hi.
<osfesa>
I'm back with Issue4145. I've got a forked repo. Where I've got a branch with the change and my master has the change merged too. You can find them in https://github.com/osfesa/openscad/
<osfesa>
I'm unable to "see" the openscad/openscad repo when I try to pull request across forks
<InPhase>
osfesa: Have you tried it from the openscad/openscad page?
<InPhase>
Well the first oddity, is that it doesn't appear to be a normal github fork that you made.
<osfesa>
I made it from the Github page
<InPhase>
Like if we go here, which is neither of ours, we should first see "987 forks" for the thehans/openscad: https://github.com/thehans/openscad/
<InPhase>
The same appears on mine. It does not appear on yours.
<myosotis>
did you create a "new repo" and then import from openscad url? or did you click a fork button from the openscad repo?
J22 has quit [Quit: Client closed]
J22 has joined #openscad
<myosotis>
disclaimer: I've only used gitlab's UI
<osfesa>
I created a "new repo" and selected "import repository" from there. I'll try to find that fork button
<InPhase>
I think that's probably the problem, although I'm confused that it doesn't pick up that it's the same code and just let you PR it anyway.
<InPhase>
I also cannot create a PR from your code via the web interface.
<teepee>
it did PR into the repo itself as it did not see the upstream repo
<osfesa>
I'll try forking from the openscad repo. Thanks for you guidance
<myosotis>
the fork operation is a web-application specific thing, importing code from a url is a git thing. there's no real way to tell git repos apart
<myosotis>
so if it isn't forked throubh a process the ui is expecting, it can't be sure that it's really the same.
<teepee>
yeah, it's missing the remote setup
<InPhase>
I figured you could just type anything into the "Choose a Head Repository", but you can't.
<myosotis>
a fork isn't real... all copies of the repo are the same. "forks" are just a construct of your chosen git management tool
<teepee>
that import seems a bit strange, it did pull in the sponsor setup pointing to the main repo
<teepee>
well, fork is mostly a .git/config entry
<InPhase>
Hmm. So one could just edit it in?
<teepee>
probably not, I don't think github allows editing that
<myosotis>
like I'm saying, forks are a UI construct...
<InPhase>
teepee: Right, I guess you cannot edit that, and cannot push it...
<myosotis>
I can take a repo in gitlab, make a branch, and import that repo into github, and it knows about that branch... You can't do anything like that with forks, unless both apps specifically support that.
<InPhase>
Not even anything to reattach as a fork in the repository settings. *shrug*
<InPhase>
I guess there is only one true path of buttons to click.
<myosotis>
nope, I learned all of this the hard way through gitlab... if github is anything similar, your best best is to freshly fork the repo and make a patch from the work you've already done, then apply it to your fork and commit.
<teepee>
nah, working with multiple remotes is just fine
<teepee>
but you need to local repo with full access to mediate
<myosotis>
yeah, certainly playing with remotes can get your code from one repo into another
<myosotis>
I was just thinking that osfesa has vcs xp, but not git xp, so patch/apply is probably something they can already do.
<teepee>
on github you can even push into the branch of the foreign repo if the PR exists, so at least they did some access control magic
<myosotis>
<teepee> on github you can even push into the branch of the foreign repo if the PR exists, so at least they did some access control magic
<myosotis>
that sounds to me like they can fix their issue without creating a fork?
<teepee>
and there's the PR already
<teepee>
no I don't think that would work, as it requires the open PR to allow the push
<teepee>
not sure why the bot is not reporting that
<osfesa>
It worked. It was ever quicker than what I did before.
<teepee>
yep, looks good, builds are busy :)
<teepee>
argh, trying to upgrade OpenCSG, but MXE fails to build some dependency :(
<osfesa>
Which IDE do you use for OpenScad? I used QtCreator in the past, but there is no project to open.
* teepee
uses NetBeans
<teepee>
but there's no official one
<myosotis>
i have such a love/hate relationship with that editor
<myosotis>
most of my C programs are for microchip pic, so I use their editor, which is based on NetBeans. I'm sure vscode would be okay though, if you don't hate MS...
<osfesa>
I don't hate MS, but I don't like VSCode, I would like something with a good debugger.
<osfesa>
I'll try Netbeans, I remember using it at Uni
<myosotis>
it's SOOO HEAVY but it does all the things you could ever hope to want an IDE to do.
<InPhase>
osfesa: Qt Creator is pretty solid for Qt + cmake projects such as this one (and for others).
<InPhase>
osfesa: What you open is the CMakeLists.txt file.
<myosotis>
+1 for using what you already know
<teepee>
The C++ support of NetBeans is ok-ish, it's a bit old, the plugin needs to be installed from version 8
<teepee>
still twiddling thumbs for the updated C++ support getting integrated
<InPhase>
osfesa: I pretty much don't use Qt Creator for anything other than CMakeLists.txt based projects. It's the best way to work, because it makes it very easy to switch out of using the IDE to just compiling directly.
<osfesa>
version 8 is from 2014, that's not encouraging
<teepee>
it works fine with latest netbeans and supports C++14 which is what OpenSCAD uses
<teepee>
the actual debugger is gcc anyway
<InPhase>
teepee: Although I predict we might end up going C++17 later this year, as 20.04 is going to go out of fashion, and someone is eventually going to want it for something.
<teepee>
it's all due to that annyoing Oracle licensing to Apache / source code "donations"
<teepee>
true, but I don't expect a huge amount of incompatible stuff used very soon
<InPhase>
Or, not 20.04. 18.04
<InPhase>
I think that's what we were holding out on. It has been a while since this question came up.
<peeps[zen]>
<teepee> but we can start with the F6 render, I hope?
<peeps[zen]>
yeah getting the CGALRenderer to use shaders would be a nice first step. the GSoC thing says Preview though, so I was assuming that
<peeps[zen]>
of all the rendering/graphics code, i have looked at CGALRenderer the least. so I don't know a lot about how it works or how well it would translate to shader, but its a little bit odd as it uses some CGAL callbacks
<teepee>
oh, oops
<teepee>
heh, that was Sean
<teepee>
ah, no it was already saying Preview before
<peeps[zen]>
I think one thing that is important to note is that we can, and probably should use multiple shaders per scene. eg shader based axes would probably be best as their own independent thing
<peeps[zen]>
and with the way the edges/vertices callbacks work with CGAL, maybe it would be smart to have those on separate shaders from faces as well
<peeps[zen]>
also there's the whole issue of render missing access to color info though :(
<teepee>
yeah, that sounds good, I don't know the details on how that works, but hopefully there's enough time to discuss
<teepee>
well, some details can be left for later anyway, we just need to make sure the time frame is reasonable
<teepee>
it seems like the surface mesh stuff might be able to pass along extra info
KimK has quit [Ping timeout: 250 seconds]
JakeSays_ is now known as JakeSays
myosotis has quit [Remote host closed the connection]