<Guest78>
@InPhase: Guest78, but does not match my need.
<InPhase>
Guest78: That's why I asked your need. But you didn't say what it was.
<Guest78>
Well : I have a lot of pieces of MDF and I Would like to sligtly the color each time I need this "carton" color, because it¡s hard to différenciate viasualy what is what.
<Guest78>
If you know C, with 8 colors could be easyly done with a [CODE] colorTable[colorIdx=++colorIdx&07]) [/CODE]
<Guest78>
Hopping you understand
<Guest78>
I know that there are very limited possibilities to use variables, in OpenSCAD.
<InPhase>
There are not limited possibilities. It has the same capabilities as other languages, you must just structure code differently.
<InPhase>
I've been trying to advise how to do this, but you are doing what's called an xy problem.
<InPhase>
https://xyproblem.info/ You're explaining how you're trying to solve the problem, but not so much about what you're trying to solve.
<InPhase>
The answer is in the x of what you're trying to solve, not the y of how you tried to solve it.
Guest40 has joined #openscad
Guest40 has quit [Client Quit]
GNUmoon has quit [Ping timeout: 244 seconds]
GNUmoon has joined #openscad
<Guest78>
Thanks
<Guest78>
Bye, folks !
Guest78 has quit [Quit: Client closed]
sculptor has quit [Remote host closed the connection]
sculptor has joined #openscad
_whitelogger has joined #openscad
Guest26 has joined #openscad
mmu_man has quit [Ping timeout: 252 seconds]
J25k21 has joined #openscad
mmu_man has joined #openscad
J25k20 has quit [Ping timeout: 272 seconds]
snaked has joined #openscad
Guest26 has quit [Ping timeout: 272 seconds]
snaked has quit [Ping timeout: 260 seconds]
mmu_man has quit [Ping timeout: 240 seconds]
sculptor has quit [Quit: Leaving]
snaked has joined #openscad
J25k21 has quit [Quit: Client closed]
J25k21 has joined #openscad
J25k21 has quit [Quit: Client closed]
J25k21 has joined #openscad
J25k21 has quit [Quit: Client closed]
J25k21 has joined #openscad
howiemnt has quit [Remote host closed the connection]
howiemnt has quit [Remote host closed the connection]
j45 has joined #openscad
j45 has joined #openscad
j45_ has quit [Ping timeout: 248 seconds]
howiemnt has joined #openscad
j45 has quit [Ping timeout: 260 seconds]
howiemnt has quit [Ping timeout: 260 seconds]
J25k21 has quit [Quit: Client closed]
J25k21 has joined #openscad
<JordanBrown1>
teepee it's not exactly correct to say that OpenSCAD has no integers. It has no distinct integer type. It does, however, certainly have numbers with integer values. That can be important at times - if you're trying to blame a problem on floating point inaccuracy, but the values are all integers, it isn't floating point inaccuracy.
<bitbasher>
FP inaccuracy only comes into it if one of the number is calculated in an expression and is large enough that its least significant digits get dropped and the exponent has to be moved off of zero
<JordanBrown1>
No, it can be a real problem with small numbers too. But it's a problem much more rarely than people think.
<JordanBrown1>
It would not be at all surprising if 1/3 + 1/3 + 1/3 does not equal 1.
<JordanBrown1>
And trig functions are likely to have accuracy problems.
<JordanBrown1>
Not enough to be visible, but enough that you might not get *precisely* the mathematically correct result.
<bitbasher>
i was working on a library function, wrote some tests using assert and could NOT figure out why the asserts were blocking .. till i realized that i was comparing an expressoins result to an integer ..
<JordanBrown1>
yep.
<bitbasher>
then of course i was off on a side project to build a nearly_equal() function .. the rabbit hole was deep on that one
<JordanBrown1>
The most common problem is that 1/5 is an infinite repeating fraction in binary, and so cannot be represented precisely... and because of that 1/10 cannot be represented precisely either.
<JordanBrown1>
The classic example is adding up a column of dollars and cents and not coming up with the right answer.
<JordanBrown1>
This is a problem in any base, but we're used to it not being a problem with numbers represented in decimal.
<othx>
guso78k linked to YouTube video "Landscape modelling in PythonSCAD" => 1 IRC mentions
<JordanBrown1>
Absolutely they are different.
<JordanBrown1>
But that ray tracing explanation is not how it works.
<guso78k>
This is my result. unfortunatly i am not an artist, but rather programmer
<JordanBrown1>
Considering only unions for a moment, the way that it really works is that we throw all of the triangles at the graphics subsystem.
<JordanBrown1>
For each triangle, it calculates which pixels that triangle appears at, and for each pixel how deep (how far away from the viewer) that pixel is.
<JordanBrown1>
Then it looks at the pixel that's already on the screen, and if the new pixel is further away then it's discarded, and if it's closer then it replaces the old pixel.
<JordanBrown1>
Difference and intersection use more complex tricks but the same basic engine.
<bitbasher>
the mention of OpenCSG was to show convexity was only relevant to it, and not to F6 rendering
<guso78k>
actually this only works with preview. Trying that to render is perfect testcase to crash Manifold :(
<bitbasher>
Jordan .. those last comments are about preview right? cause your expo meshes with mine
<JordanBrown1>
yes.
<JordanBrown1>
Somewhere - probably not this section - should discuss the difference between F5 preview and F6 render, but it only needs to be to the extent of explaining that preview is a fast way to yield a 2D image, while rendering actually calculates the entire shape.
<bitbasher>
k .. thot so .. i wrote my first frame buffer in unit in 1978 or so
<bitbasher>
but getting into the depth search stuff is only good for solving insomnia in the reader
<bitbasher>
in my docs this:
<bitbasher>
difference between F5 preview and F6 render, but it only needs to be to the extent of explaining that preview is a fast way to yield a
<bitbasher>
is exactly the point of the Rendering page
<JordanBrown1>
Right. Once you have explained the difference between render and preview, the only things that you really need to say about convexity are the blob-with-red-line image and the example-problem image.
<bitbasher>
.. sigh .. i am bravely going to try to integrate your depth search suggestion into my text
<JordanBrown1>
Hmm?
<JordanBrown1>
First, there's no searching.
<JordanBrown1>
But second, that was for your interest, an explanation of how the ray-tracing explanation was just wrong.
<JordanBrown1>
I don't think you should explain the algorithms *at all*.
<JordanBrown1>
Just "preview is fast and yields 2D, render takes longer and calculates the entire 3D shape".
<bitbasher>
well .. ok .. yes one is only keeping the Z depth of the last displayed object in the pixel so really it is just a comparison
<JordanBrown1>
Maybe a link off to some external pages that discuss the issues.
<JordanBrown1>
Right, just a comparison, which is why it's often done in hardware.
<JordanBrown1>
And *really* the advice for convexity is "this is what a convexity problem looks like, and if you see this then add "convexity=10" to your call and it will probably go away".
<bitbasher>
what ? and disappoint all the nerds that hate getting an explanation that does nothing more than hand waving -- grins
<JordanBrown1>
Curve smoothness is *not* a rendering issue. It controls the actual generated 3D model.
<bitbasher>
ah .. but in terms of what the user sees .. when the sphere previews as a five sided polyhedron it is a rendering issue
<JordanBrown1>
Nope.
<JordanBrown1>
It doesn't *preview* as a five-sided polyhedron.
<JordanBrown1>
It *is* a five-sided polyhedron.
<JordanBrown1>
circle(); with everything default *is* a pentagon.
<bitbasher>
oh? i thot it was only a math model until it was F6 rendered as that is when actual polygons were created
<JordanBrown1>
There are no curves.
<JordanBrown1>
I'm not sure exactly where the conversion happens, but it's pretty high in the stack.
<JordanBrown1>
F5 and F6 produce exactly the same results.
<JordanBrown1>
And the various boolean operations are definitely done on the line-segment approximations, *not* on the theoretical curves.
<bitbasher>
but the "inner model" is a math circle, or sphere, that is approximated for display .. until u have a mesh you have not limited the appearance by the $fn etc "smoothness" variables
<JordanBrown1>
Eh, no.
<bitbasher>
various boolean operations are definitely done on the line-segment approximations, *not* on the theoretical curves. ... this is interesting to know
<JordanBrown1>
It's easiest to demonstrate with $fn, but of course small values of $fn are not usually interesting if you're thinking of circles.
<bitbasher>
actually .. i could use clarification one the diffs between what everyone calls F5 and F6 .. as if they were two completely diff ways to render the model
<JordanBrown1>
If those were mathematical circles, you would expect that their intersection would be non-empty.
guso78k has quit [Quit: Client closed]
<JordanBrown1>
You would expect that their difference would take a bit out of one side of one of them.
<JordanBrown1>
But neither of those happen.
<JordanBrown1>
They are squares.
<JordanBrown1>
If you feel like doing the work, you could replace circle() with a module that does math and calls polygon().
<bitbasher>
right .. that illuminates
<JordanBrown1>
I don't think that happens right at the top level of processing, but it's well above the part that does anything complicated.
<JordanBrown1>
and it's absolutely the same for F5 or F6.
<bitbasher>
so .. what is the diff between F5 and F6?
<JordanBrown1>
As for differences between F5 and F6... not that it should be in the documentation (except maybe in some deep-dive page, not at the top level)
<JordanBrown1>
...
<JordanBrown1>
The high-level answer is that F5 is a fast scheme that produces a 2D image, while F6 actually calculates the resulting shape.
<JordanBrown1>
Consider this figure:
<JordanBrown1>
cube(10);
<JordanBrown1>
cube(10, center=true);
<bitbasher>
well .. i would like to at least clarify for the reader why there are 2 functions .. other than F5 updates the preview after changes to the script
ccox has joined #openscad
<JordanBrown1>
So does F6, but F6 is a little slower (historically a lot slower) and historically loses color information.
<JordanBrown1>
But consider that two-cube model.
<JordanBrown1>
See the lines where the two cubes intersect?
<bitbasher>
and the only time i have needed F6 was when i tried to export a mesh to .obj or .stl and got warned it needed whatever F6 was doing for me
<JordanBrown1>
(They're the bounds of a 5x5 cube.)
<JordanBrown1>
F5 does not know that those lines exist.
<bitbasher>
yes i see the 5x5 cube boundaries
<JordanBrown1>
F6 knows about them.
<JordanBrown1>
F5 literally does not know that they exist. It draws the faces of the cubes, and the graphics subsystem (typically but not always a GPU) figures out which pixels are in front.
<bitbasher>
ah .. i see what you mean .. a z-buffer could care less about the intersections
<JordanBrown1>
F6 figures out the probably four triangles that make up each of those L-shaped faces.
ccox_ has quit [Ping timeout: 276 seconds]
<JordanBrown1>
From F5's point of view, there are edges *inside* the model that are just as real as the ones on the outside.
<JordanBrown1>
F6 knows that those edges are destroyed by the union.
<JordanBrown1>
Difference is really magic in F5 and I'm not quite sure how it works, but stuff that's differenced away is still "there" in some sense, just hidden by other pixels.
<JordanBrown1>
F6, on the other hand, actually removes the stuff that is differenced away.
<JordanBrown1>
It took me a long time to understand how preview could work without calculating the shape of the model.
<JordanBrown1>
The key thing that I was missing was that preview is entirely relative to the camera's position.
<bitbasher>
when i read up on OpenCSG it was talking about z buffering .. my draft text was just riffing on making that understandable to the reader
<bitbasher>
until tthey come up against rendering issues .. typically in preview .. that playing with $fn does not solve
<JordanBrown1>
When you are previewing and you move the camera, it recalculates what you see. It doesn't run the program again, but it *does* throw all of the triangles at the GPU, does all of the black magic for difference, et cetera.
<JordanBrown1>
F6, on the other hand, generates a single polyhedron, and never has to do any other calculation on it.
<bitbasher>
and now perhaps if you can take the average user's viewpoint .. there are three views of the model
<JordanBrown1>
(Except that to actually put it on the screen, I assume that F6 does the same sort of GPU stuff. The direct result of F6 is *not* dependent on the camera angle.
<JordanBrown1>
)
<bitbasher>
the math model that is embodied in the script
<bitbasher>
the preview
<bitbasher>
and the render
<JordanBrown1>
Playing with $fn/$fs/$fa *never* affects rendering issues, except maybe indirectly.
<JordanBrown1>
(e.g. changes in those might change the convexity of your model, or might make faces be coplanar.)
<JordanBrown1>
But again, $fn/$fs/$fa do not control rendering. They control the actual generated shape, not merely the display presentation of the shape.
<JordanBrown1>
Going back to the document, I'm not sure that the generated number of segments is always an integer.
<bitbasher>
exactly .. that indirectly makes it look like a rendering issue .. that is how i thot of it when i first encountered issues of union and intersection in preview
<bitbasher>
the code makes it an integer
<JordanBrown1>
Yeah, but in that sense every single thing about your model is a rendering issue.
<JordanBrown1>
as for "integer number of fragments"... experimenting.
<JordanBrown1>
Yeah, it does look like it does.
<JordanBrown1>
Clearly a circle can never be built from a non-integer number of segments.
<JordanBrown1>
But a rotate_extrude() with the angle parameter could be.
<JordanBrown1>
... but isn't.
<bitbasher>
yep .. that sample code in the docs is very close to what is in the actuall code
<JordanBrown1>
Yes.
<JordanBrown1>
It's actually technically wrong; the definition of $fs is wrong. But it's a subtle error.
<bitbasher>
how so?
<JordanBrown1>
$fs says that it's the minimum length of a segment.
<JordanBrown1>
That is, of a chord.
<bitbasher>
yep
<JordanBrown1>
but it's really the minimum length of an arg.
<JordanBrown1>
arc
<bitbasher>
umm .. those are really close to the same thing
<JordanBrown1>
I did say that it's subtle.
<JordanBrown1>
They are *not* the same, but for reasonable values they are very close.
<bitbasher>
at least .. when calculating segments to divide a curve into
<JordanBrown1>
As long as you're talking about tens of segments, the difference is small.
<JordanBrown1>
But also, the best way to think about it is that $fs and $fa are about controlling how precisely you want your round things represented.
<JordanBrown1>
Don't overthink exactly what they do.
<JordanBrown1>
$fs controls the behavior of small circles; $fa controls the behavior of large circles.
<JordanBrown1>
smaller numbers mean more accurate, and also mean slower and bigger files.
<JordanBrown1>
For most purposes, you can set $fs=0.5 and $fa=1 and forget it.
<JordanBrown1>
And if you're actually working with circles, you should never use $fn.
<JordanBrown1>
You should use $fn only to create regular polygons.
<bitbasher>
now see .. that right there should be in the modelling pages as notes on drawing curved shapes
<JordanBrown1>
The commentary that you've got about $fn is ... misleading.
<JordanBrown1>
The $fn value that you would need is very much dependent on the size of the circle.
<JordanBrown1>
For all but the smallest circles, $fn=20 is not enough.
<JordanBrown1>
It has significant flat sides.
<bitbasher>
yes .. but for preview and developing a new model 20 is fine
<JordanBrown1>
Don't do it.
<JordanBrown1>
Just don't.
<JordanBrown1>
If you really feel a need to have "make it fast while I'm working" values, adjust $fa and $fs.
<bitbasher>
any user will see that much larger values are needed to ensure the resulting mesh is good enough for rendering, or 3D printing
<JordanBrown1>
If you just set $fn, it will probably be too large for small circles and too small for large circles.
<JordanBrown1>
If you set $fs=0.5 and $fa=1 you will get good circles at any size.
<JordanBrown1>
As long as you're working in plastic at macroscopic scales, at least. If you're working in metal, you'll want smaller sides because everything is sharper.
<JordanBrown1>
If you're working at micro scales, you need more sides.
<bitbasher>
hummm .. well okay .. gave up trying to find easy to write down rules of thumb to guilde using $fs and $fa .. they interact so much .. and size of curve (radius) comes into it .. nightmare
<JordanBrown1>
The rule of thumb is what I said above.
<JordanBrown1>
$fs=0.5; $fa=1.
<JordanBrown1>
$fs controls the minimum size of a side of a small circle, and keeps you from having a circle with a bunch of microscopic sides that your printer can never reproduce anyway.
<JordanBrown1>
$fa controls the minimum angle between sides, and again keeps you from producing a large circle with a bunch of microscopic sides.
<JordanBrown1>
Or, rather, with a bunch of sides that have such small angles between them that you can't tell the difference.
<JordanBrown1>
But globally setting, say, $fn=60, is just a misake.
<JordanBrown1>
mistake
<bitbasher>
of course .. elsewhere i suggest using $preview and an IF statement to set high and low values for it ..
<JordanBrown1>
if you're making a 5mm diameter circle, $fn=60 is ~0.5mm sides, only maybe perceptible.
<JordanBrown1>
But if you're making a 100mm circle, $fn=60 has sides that are 10mm across, entirely visible.
<bitbasher>
for people starting out in scad that is a decent start .. with experience they will figure out the intricacies
j45 has joined #openscad
j45 has quit [Changing host]
j45 has joined #openscad
<JordanBrown1>
but they are going down the wrong rabbit hole.
<JordanBrown1>
One of the most common questions is "why does it take so long for my model to render"
<bitbasher>
they wont .. once i have re-written the whole page .. AGAIN .. to bring in all the new insight you have given me
<JordanBrown1>
and the answer is "because you have spheres with a zillion microscopic sides.
<JordanBrown1>
"
<bitbasher>
and that should be a FAQ .. i need to check the list
<JordanBrown1>
$fs/$fa are a little harder to understand, but are mostly "set and forget".
<JordanBrown1>
It is entirely reasonable to set $fs=0.5; $fa=1; at the top of your file and never think about it again.
<bitbasher>
i refer u back to my rant about how getting those two to work correctly is a nightmare ..
<JordanBrown1>
If you *really* want to optimize performance, maybe set $fs=1; $fa=2;.
<JordanBrown1>
First you have to define what "work correctly" is.
<JordanBrown1>
Just set them both to numbers around 1, and you'll get fine results.
<bitbasher>
change it to "work at all"
<JordanBrown1>
Bah. They work fine as long as you don't set them to silly values.
<JordanBrown1>
Though I do have to say that the default values are a bit on the silly side.
<bitbasher>
LOL . i knew you were a scroog at heart .. you emitting half of a "bah humbug" .. i am on to you now
<JordanBrown1>
The defaults are $fs=2 and $fa=12, and 2mm sides are easily visible on small circles, and 12° sides are very visible on large circles.
<JordanBrown1>
Try setting $fs=0.5; $fa=1; and see if you ever have any issues.
<bitbasher>
The fs fa defaults are how prim circle and sphere show as 5 sided .. i suspect the OG coder chose that as a design goal and wrote the defaults to match
<JordanBrown1>
I think the answer is that the defaults were established 12+ years ago and memory and CPU were more of a consideration.
<bitbasher>
this will now be my mantra .. and i will rework the docs to clarify that fn etc really affect geometry so our readers understand the whole mess as well as you do .. and me, now that you have informed me
howiemnt has joined #openscad
<JordanBrown1>
All three affect geometry.
<bitbasher>
fn etc. was a short form
<JordanBrown1>
The best way to think of it is that $fs and $fa control circle quality, while
<JordanBrown1>
$fn controls the number of sides of a regular polygon.
<bitbasher>
oh .. that goes in the FAQ too .. that is nice and consise
<JordanBrown1>
Now try doing that with any *single* setting of $fn.
<JordanBrown1>
That's probably a 360-gon for the big circle, which would be absurd for the small circle.
<bitbasher>
say .. when fn etc are given as arguments to a module .. they are local settings right? they dont affect the global values ?
<JordanBrown1>
For a long time I thought that $fa=5 was mostly small enough, but somebody told me that you really could see the sides of a 72-gon if it was fairly large
<bitbasher>
or is that the special variable thing with the stack depth again?
<JordanBrown1>
so I printed a segment of a 100mm radius circle at $fa=5 and yeah, they're visible.
<JordanBrown1>
With respect to scope...
<JordanBrown1>
$fn/$fa/$fs are not at all special, except in being $ variables. They have exactly the same scoping behavior as any other $ variables.
<JordanBrown1>
... which means that wherever you set them, applies to that scope and anything that that scope calls.
<bitbasher>
well .. using them as arguments in a call to a module .. that is a subtle diff no?
<bitbasher>
BRB
<JordanBrown1>
no, it just sets them for that call.
<JordanBrown1>
(and everything called underneath that.)
<JordanBrown1>
continuing document review...
<bitbasher>
sure .. i am up for more if u have the time
<JordanBrown1>
I'd say that the paragraph "curved 3D objects are sliced..." is both more detail than appropriate and not entirely accurate.
<JordanBrown1>
First, it sure would be nice if we changed to a different algorithm for spheres.
<JordanBrown1>
Nobody likes the current one, and really nobody should be depending on it.
<JordanBrown1>
In particular, the fact that the north and south poles are flat rather than pointy is annoying.
<JordanBrown1>
But also there are much better algorithms, that produce better results with fewer faces.
<JordanBrown1>
The more that people "know" about the algorithms used, the less flexibility we have to make them better.
<JordanBrown1>
"But you promised that the top of a sphere would be flat!"
<bitbasher>
all that said, and without prejudice, i am just trying to show the connection between the generated poly surface and the fn etc. settings
<JordanBrown1>
Yeah, understood, but mostly "pay no attention to the man behind the curtain".
<bitbasher>
would saying "this is how we do now, may change in furure" cover it ..
<JordanBrown1>
The behavior of spheres in particular is non-obvious *and* there's really no need to understand it.
<bitbasher>
my udnerstanding is the current way of work is the original no?
<JordanBrown1>
I'm sure it is.
<JordanBrown1>
Well, except maybe to understand that spheres are crummy and if you care about precision in sphere-like objects you probably want to roll your own.
<bitbasher>
LOL
<bitbasher>
heh .. if i need a good sphere i will open FreeCAD or some such
<JordanBrown1>
Indeed subdivision is used on curves imported from DXF files. (And SVG files, though I think there's some controversy as to how they should be used there.)
<JordanBrown1>
But they are not used on STL files ... because STL files do not contain curves.
<bitbasher>
yep .. the T is for Triangle
<JordanBrown1>
Or for the T in Stereo.
<JordanBrown1>
>Chuck Hull, the inventor of stereolithography and 3D Systems’ founder, reports that the file extension is an abbreviation for stereolithography
<bitbasher>
yeah .. i saw that too .. i still thing triangle when reading STL even tho it makes little sense
<JordanBrown1>
All values of $fn, not just very low ones, can be used to create regular polygons. It's just that very few people are interested in creating, say, 37-gons.
<bitbasher>
about the .. are sliced .. para .. i will have a go at further simplifying
<bitbasher>
the 42-gone is the answer to life and the universe
<JordanBrown1>
That's true. So it's important that you can create one.
<JordanBrown1>
A description of $fs and $fa should focus on $fs controlling the number of sides on small circles, while $fa controls the number on large circles.
<JordanBrown1>
I've occasionally done the math to calculate where one takes over from the other, but mostly it doesn't matter.
<JordanBrown1>
Generally speaking, if you're trying to take $fs and $fa and calculate the number of sides, you're doing something wrong.
<JordanBrown1>
Including the equation is sort of good from a completeness perspective, but it's rare that you really need to do the calculation.
<bitbasher>
the pragmatic approach can solve that .. if you are 3D printing use values in the model that make the print work and look right
<bitbasher>
same for rendered images
<JordanBrown1>
Sure. And $fs=0.5; $fa=1; are those values for almost all models. :-)
<bitbasher>
the code for poly divisions really help my understanding of how fn works solo which fa and fs are considered together, but once u have the size of the curve on of them is selected over the other
<JordanBrown1>
Again, the scope rules for these variables are exactly the same as the scope rules for any $ variables.
<JordanBrown1>
Set in a scope, they apply to that scope and anything that it calls. Set in a call, they apply to that call and everything it calls.
<JordanBrown1>
And, like $ variables and normal variables, there's an apparent exception to the "you can't change variables" rule.
<bitbasher>
humm .. does it matter then that $fn etc are set as parameter in a call .. as opposed to setting them inside the definition of a module ?
<JordanBrown1>
You cannot set a variable that has been set in the current scope. (There are a few magic exceptions associated with include<>, the CLI's -D option, and the Customizer.)
<JordanBrown1>
Does it matter? Yes, no, maybe? It affects the scope.
<JordanBrown1>
will have the $fn setting apply to yourmod().
<bitbasher>
but i will get into that rabbit hole another day
<JordanBrown1>
Going back to "overwriting" variables...
<JordanBrown1>
You cannot set a variable that has already been set in the current scope.
<JordanBrown1>
But you can create a *new* variable with the same name as a variable in a higher scope.
<bitbasher>
so .. we have made it 4 paras into my Rendering page .. comments on anything further down?
<JordanBrown1>
And you can create that variable with a value based on the higher-level value.
<JordanBrown1>
So you *can* say x=x+1, if there's an x defined in a higher scope.
<JordanBrown1>
And it creates a new x, not affecting the higher scope's x.
<JordanBrown1>
The $vp* variables reflect the current viewport parameters at the time of program execution, whether it's F5 or F6.
<JordanBrown1>
I would tend to spin them as camera parameters, though I always have to think about exactly what they mean.
<bitbasher>
yeah .. that point was made .. somewhere i read it
<JordanBrown1>
You said "at the time of rendering".
<bitbasher>
the term viewport params works for me
<JordanBrown1>
I think a camera is a more intuitive concept.
<bitbasher>
umm .. that was what i understood .. there was a warning somewhere that the VP values were not affected by changes in the script but only by changes in the mesh gen'd by F6
<JordanBrown1>
Not true.
<bitbasher>
ah
<JordanBrown1>
They are not affected when you simply pan/rotate/zoom the display, but any time that you run the program they are set.
<JordanBrown1>
It is both good and bad that the program is not run every time you pan/rotate/zoom.
<bitbasher>
ah right .. that was it
<JordanBrown1>
It would be very slow.
sculptor_ is now known as sculptor
<JordanBrown1>
I would probably downplay or remove the animation tie-in, or move it to a "tips and tricks" section.
<JordanBrown1>
animation is not special here, other than that it runs the program over and over again.
<JordanBrown1>
I'm a little surprised by the "not in an include<>" statement, but I can't say that I've ever tried it.
<JordanBrown1>
Mostly, it's hard for anything to detect that it's being used in an include<>.
<JordanBrown1>
It's hard even for internal things to tell.
J25k21 has quit [Quit: Client closed]
<JordanBrown1>
(Not impossible, but they have to go out of their way.)
J25k21 has joined #openscad
<sculptor>
here's an idea - to pass arguments to .scad file
<bitbasher>
that came from an explicit mention of the issue and my experiments verified it
<JordanBrown1>
sculptor what is to pass args to the .scad file?
<sculptor>
'd be a cool feature
<JordanBrown1>
That's what -D is for in the CLI, or the Customizer in the GUI.
<bitbasher>
sculptor - yeah, include <file.scad>( arglist ) could be done .. syntactially at least
<JordanBrown1>
semantically it wouldn't work.
<JordanBrown1>
include<> is (like in C, but more so) a textual substitution.
<JordanBrown1>
so it is perfectly valid to say
<JordanBrown1>
x = [
<JordanBrown1>
include <values.txt>
<JordanBrown1>
];
<bitbasher>
no .. semantics means overcoming some nasty issues
<JordanBrown1>
I don't think there's even any whitespace implied, though you have to be really careful to avoid accidentally introducing any.
<JordanBrown1>
But try this
<JordanBrown1>
if (include < 5 && include > 2) echo("hello");
<JordanBrown1>
hence the "but more so".
<bitbasher>
ouch .. that really is a pure text replacement thing
<sculptor>
there's a prog language that only uses whitespace - space and tab
<sculptor>
and linefeed. it's called Whitespace
<JordanBrown1>
I'm not surprised.
<bitbasher>
someone had 1.0e-300 life and time^100/ hands
<JordanBrown1>
Yes.
<JordanBrown1>
In the $preview section, in the "When OpenSCAD is run from the command line" paragraph, drop the "with CGAL" phrase.
<JordanBrown1>
First, mostly today you use Manifold, not CGAL.
<JordanBrown1>
Second, mostly if you're generating DXF or SVG you're not using either of those.
<JordanBrown1>
(Exception: if you make a 3D object and then flatten it with projection().)
<JordanBrown1>
Also drop the "with OpenCSG" phrase. While true, it's also an internal implementation detail.
<JordanBrown1>
And that's the end.
<bitbasher>
wait one .. does export do its own tesselation of shapes into meshes ? separate from what is done for rendering?
<JordanBrown1>
No, at least mostly not.
<bitbasher>
when i export to .obj i get warned to do F6 to make a mesh needed for the exporting
<JordanBrown1>
Sure.
<JordanBrown1>
For anything but an image you need F6.
<bitbasher>
so that clearly uses the mesh .. is not export for DXF n STL the same?
<JordanBrown1>
Yes, and those need F6 too.
<JordanBrown1>
F6 yields a mesh (or its 2D equivalent).
<bitbasher>
and even for the image u need F6 to solve poss intersection and union joins issues yes?
<JordanBrown1>
Today, I don't think that any exporter needs to do anything to that mesh.
<JordanBrown1>
No, image exports are the same as displaying on the screen; they only need the preview logic.
<JordanBrown1>
NB that SVG and DXF are not image formats.
<bitbasher>
The OBJ export just added an addition Make Triangles step to solve a bug
<JordanBrown1>
yes
<JordanBrown1>
Today, with Manifold, I believe that everything is a triangle.
<JordanBrown1>
But that's not a limitation for CGAL, and so CGAL would generate non-triangular faces.
<JordanBrown1>
And some OBJ consumers can't handle those.
<JordanBrown1>
so the OBJ exporter will split apart non-triangles.
<bitbasher>
then .. manifold is not used to make the polygons for a curved object?
<JordanBrown1>
Er... I suppose that it depends on your POV.
<JordanBrown1>
Manifold does not process curves.
<JordanBrown1>
When you make a sphere or a cylinder or ... OpenSCAD turns that into a set of triangles, and Manifold processes the triangles.
<bitbasher>
so something else makes the polys that are based on the math of a curved shape, and THEN Manifold makes a mesh from that?
<bitbasher>
does not seem .. sensible
<JordanBrown1>
yes
<JordanBrown1>
doing 3D boolean operations is hard enough on polyhedra :-)
<bitbasher>
but that is wrong .. scad makes shapes out of quads and n-gons .. not triangles
<JordanBrown1>
not once it gets to Manifold.
<JordanBrown1>
(As I understand it. I haven't looked at the details.)
<JordanBrown1>
is the processing to construct a sphere.
<JordanBrown1>
It's not super obvious, but it's not that bad either.
<JordanBrown1>
It's basically exactly the same processing that you would do to DIY it with polyhedron().
<bitbasher>
but then .. when does it get to manifold .. i do cylinder() in scad and i get quads around the outside and n-gons for top and bottom
<bitbasher>
yeah .. that is the code i found too
<JordanBrown1>
Again, View/Show Edges and F5 and F6
<JordanBrown1>
I guess that doesn't prove that the *input* to Manifold is triangles, but the output certainly is.
<bitbasher>
so manifold has nothing to do with making geometry .. nor with preview?
<JordanBrown1>
Correct.
<JordanBrown1>
Assuming that you do not consider a union/difference/et cetera operation to be part of "making geometry".
howiemnt has quit [Remote host closed the connection]
<JordanBrown1>
And excluding the render() module, which forces a full Manifold-or-CGAL render of its children.
<bitbasher>
oh wait .. i gen a cylinder .. edges show quads .. tap F6 and it is all triangles .. so manifold is in play
<JordanBrown1>
Manifold is definitely in play when you F6.
<JordanBrown1>
(Well... maybe. There might be a special-ish case for a single primitive.)
<JordanBrown1>
But the full triangular tesselation is in play.
<JordanBrown1>
I suspect that there are other modules (hull, projection, minkowski, resize) that force a render.
<bitbasher>
hull seems to force a render
<JordanBrown1>
Kind of has to.
<JordanBrown1>
It needs to know what vertexes are actually left.
<JordanBrown1>
Again, preview really doesn't know anything about the resulting shape, hard as it may be to believe.
<bitbasher>
that is so .. but when the orig shapes are replaced with the mesh of the union / intersection .. whatever then it is doing z buffer on the mesh
<bitbasher>
so no, preview's process does not change, but the rendered image should be a lot more accurate
<JordanBrown1>
If the end product is the display or a PNG file, yes.
<JordanBrown1>
So the simplest elements of the preview scheme apply no matter what.
<bitbasher>
yep .. now i have to get to sleep
<JordanBrown1>
The render processing yields a mesh, and doesn't know where the camera is.
<JordanBrown1>
And I should pretend to do real work.
<bitbasher>
you have been a great help to me Jordan .. thx !
<JordanBrown1>
You're welcome.
<bitbasher>
i dont work at all these days .. just trying to find ways to be useful
<JordanBrown1>
Now I am really flipping over to my work computer and won't be able to see this any more...