OpenCSG doesn't even know where the vertices are in a union, difference or intersection. It just draws all the original objects using special tricks with the z buffer to create the boolean op result. On Sat, 15 Oct 2022 at 15:27, neri-engineering via Discuss < discuss@lists.openscad.org> wrote: > > > > ---------- Forwarded message ---------- > From: neri-engineering <neri-engineering@protonmail.com> > To: OpenSCAD general discussion Mailing-list <discuss@lists.openscad.org> > Cc: > Bcc: > Date: Sat, 15 Oct 2022 14:01:40 +0000 > Subject: [OpenSCAD] Re: 100% ambient light source? Simple > Yes, I noticed this also, with the two or more lights emitted by OpenCSG. > It's apparent. I would like to look into the ambient light change I > propose. Activating that change may be done with an environment variable, > perhaps. Thanks for the info. Ambient light is always easier than actual > lighting because there is no computation, no surface normal info is needed, > no color interpolation is needed. > > Another possible feature to OpenSCG would be (and I may just spouting > garbage off the top of my head, perhaps) Gouraud shading. For a system > that already does z-buffering, the addition of Gouraud shading is quite > simple because it's analogous. It's just a linear color interpolation > between vertices - just like z-buffering is. The only needed element is > not just the face/polygon to render, but also the touching polygons, so > that surface normals can be computed not for the face but rather at the > vertex, as a function of the faces touching that vertex. May or may not be > possible. Just an idea. Could be a hidden feature triggered by > environment variable. OpenSCAD and OpenCSG already to a great job. > > Sent with Proton Mail <https://proton.me/> secure email. > > ------- Original Message ------- > On Saturday, October 15th, 2022 at 3:33 AM, nop head <nop.head@gmail.com> > wrote: > > OpenCSG, which is used for the preview, has a peculiar lighting model. It > is lit from above but also from below with a second diametrically opposed > light for some trick to do with inside faces. Perhaps it could detect if > all the objects were 2D and viewed orthogonally from +Z and then use a > simpler model. > > On Sat, 15 Oct 2022 at 01:51, neri-engineering via Discuss < > discuss@lists.openscad.org> wrote: > >> >> >> >> ---------- Forwarded message ---------- >> From: neri-engineering <neri-engineering@protonmail.com> >> To: OpenSCAD general discussion Mailing-list <discuss@lists.openscad.org> >> Cc: >> Bcc: >> Date: Sat, 15 Oct 2022 00:50:23 +0000 >> Subject: [OpenSCAD] 100% ambient light source? Simple >> Before I explain the feature I'm looking for, I want to state that I am >> using OpenSCAD "to the limit" when it comes to generating computer >> animations of mechanical devices & assembly videos. OpenSCAD is very >> suitable for generating animations in many cases, because if you stay in >> that application you can handle dynamically generated parts without trying >> to "re-animate" them in a tool such as Blender. Springs that compress and >> decompress are a simple example of this. >> >> That being said, OpenSCAD has been extremely powerful for me in many >> cases, and I've avoided moving to a tool such as Blender altogether. >> >> However there is one simple case, where I actually want _LESS_ features >> than what OpenSCAD already has. This is related to the lighting model. I'm >> actually generating my computer animation frames, one by one, from the >> command line, by varying 't' and by varying the gimbal camera position in >> an intelligent manner, using cosine interpolations between various camera >> stopping points, etc. >> >> The need I have of OpenSCAD is to generate 2D cutaways and graphs. I have >> already done this with great success: >> >> https://odysee.com/@Neri_Engineering/profiles >> >> https://odysee.com/@Neri_Engineering/gimbal-cv-ver1-360-orange-green-calc-40-incident >> >> However for generation of such animations, which OpenSCAD is great at, >> and by using the "ortho" projection of course, it would be nice to have a >> lighting model which shines equally on every surface, at 100%, regardless >> of normal angle of surface with respect to light source(s). If you can >> imagine how horrendous this would look in the 3D view for example, you may >> have a toothed gear of one color where you can't make out the teeth at all, >> and you only see the silhouette of the entire gear in one solid color, in >> contrast to the background. Yes, it would look ugly. Yes, I understand why >> such an "ambient light" feature hasn't been implemented into OpenSCAD. I >> have no doubts about that. But, if you realize for a moment that the >> ambient light model is a simplification of the current lighting model, and >> that it would fill a certain need of generating 2D images, then you see >> that it would actually serve a great purpose. Especially considering that >> OpenSCAD is already so powerful at generating graphs & 2D images. >> >> In the example of the graph video above, the graph line is being drawn by >> spheres. Many of them. Yes, I could use cubes instead so that the color >> across the width of the line is more constant. But that is besides the >> point. The color on the visible face of the cube would still be affected by >> the angle that it makes with the light source(s). In these sorts of cases >> it makes more sense to have a 100% ambient light source, that lights up >> every surface to exactly that color which it's assigned to. >> >> In the 2D cross sectional diagrams (video above as well) the same problem >> - the color of the cross section is affected slightly by the angle of the >> surface in 3D. A simpler strategy would be to employ a 100% ambient >> lighting model. >> >> Furthermore a 100% ambient lighting model would not be difficult to >> implement. In fact it would likely be nothing more than taking away the >> feature of having the more intricate lighting model. I don't know how you >> would expose such a strange feature in the UI, though. Maybe it could be an >> Easter egg feature, or a hidden feature available only from command line. >> >> I am seeking to do this. I can find the area of code myself, and make the >> modifications necessary. But I don't know where to start looking. I am not >> looking for a workaround, e.g. by rotating the entire piece, along with the >> camera, to be aligned with the light source. In this case, I've decided, no >> workaround. Only implementation of the feature proposed. >> >> I was wondering if anyone has run across this problem before and/or where >> I would begin messing with the code, or maybe even it's a library that's >> outside of OpenSCAD. Also I'm a bit hesitant to set up the build >> environment for OpenSCAD, as it was installed in binary form via package >> system on Ubuntu 22. >> >> Respectfully, >> Nerius >> >> Sent with Proton Mail <https://proton.me/> secure email. >> >> >> >> ---------- Forwarded message ---------- >> From: neri-engineering via Discuss <discuss@lists.openscad.org> >> To: OpenSCAD general discussion Mailing-list <discuss@lists.openscad.org> >> Cc: neri-engineering <neri-engineering@protonmail.com> >> Bcc: >> Date: Sat, 15 Oct 2022 00:50:23 +0000 >> Subject: [OpenSCAD] 100% ambient light source? Simple >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > > > > > ---------- Forwarded message ---------- > From: neri-engineering via Discuss <discuss@lists.openscad.org> > To: OpenSCAD general discussion Mailing-list <discuss@lists.openscad.org> > Cc: neri-engineering <neri-engineering@protonmail.com> > Bcc: > Date: Sat, 15 Oct 2022 14:01:40 +0000 > Subject: [OpenSCAD] Re: 100% ambient light source? Simple > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

I realize this. But at some point in the OpenCSG code, no doubt, it renders into a pixel buffer which has z-information, using special tricks as you mention. And what does it render, I think it still renders polygons. Technically it would be a 2D polygon (after perspective or ortho transform) to render, but would have z-info on each vertex of that 2D polygon. It currently probably chooses a fixed color for any given polygon that it's going to render ("flat shading"). The polygon color is computed based on the normal to the face w.r.t. light sources, before the perspective or ortho transform. The way to "extend" the OpenCSG code to do Gouraud shading would be to pass additional info to the polygon filling routines, instead of just a single color passed to the procedure, you'd pass color info, per vertex of the polygon, in the same way that you pass the z-info per vertex. And so then the question would be how you compute the color at each vertex. Would it be easy or hard to do, the way that OpenCSG is currently structured. This explanation is highly speculative because I'm already making assumptions as far as how the "trick" rendering in OpenCSG works. I feel in my gut that it's a possible change in OpenCSG, to add Gouraud shading, without too much effort. I like the flat shading, but Gouraud could be activated by an environment variable, for example. Sometimes you'd want Gouraud shading, other times not. I think in the 3D view flat shading is perfect because it shows greater detail to the engineer, as far as where the segments are located. In a polished animation generated by OpenSCAD, in some cases Gouraud shading would be preferred. Sent with [Proton Mail](https://proton.me/) secure email. ------- Original Message ------- On Saturday, October 15th, 2022 at 9:31 AM, nop head <nop.head@gmail.com> wrote: > OpenCSG doesn't even know where the vertices are in a union, difference or intersection. It just draws all the original objects using special tricks with the z buffer to create the boolean op result. > > On Sat, 15 Oct 2022 at 15:27, neri-engineering via Discuss <discuss@lists.openscad.org> wrote: > >> ---------- Forwarded message ---------- >> From: neri-engineering <neri-engineering@protonmail.com> >> To: OpenSCAD general discussion Mailing-list <discuss@lists.openscad.org> >> Cc: >> Bcc: >> Date: Sat, 15 Oct 2022 14:01:40 +0000 >> Subject: [OpenSCAD] Re: 100% ambient light source? Simple >> >> Yes, I noticed this also, with the two or more lights emitted by OpenCSG. It's apparent. I would like to look into the ambient light change I propose. Activating that change may be done with an environment variable, perhaps. Thanks for the info. Ambient light is always easier than actual lighting because there is no computation, no surface normal info is needed, no color interpolation is needed. >> >> Another possible feature to OpenSCG would be (and I may just spouting garbage off the top of my head, perhaps) Gouraud shading. For a system that already does z-buffering, the addition of Gouraud shading is quite simple because it's analogous. It's just a linear color interpolation between vertices - just like z-buffering is. The only needed element is not just the face/polygon to render, but also the touching polygons, so that surface normals can be computed not for the face but rather at the vertex, as a function of the faces touching that vertex. May or may not be possible. Just an idea. Could be a hidden feature triggered by environment variable. OpenSCAD and OpenCSG already to a great job. >> >> Sent with [Proton Mail](https://proton.me/) secure email. >> >> ------- Original Message ------- >> On Saturday, October 15th, 2022 at 3:33 AM, nop head <nop.head@gmail.com> wrote: >> >>> OpenCSG, which is used for the preview, has a peculiar lighting model. It is lit from above but also from below with a second diametrically opposed light for some trick to do with inside faces. Perhaps it could detect if all the objects were 2D and viewed orthogonally from +Z and then use a simpler model. >>> >>> On Sat, 15 Oct 2022 at 01:51, neri-engineering via Discuss <discuss@lists.openscad.org> wrote: >>> >>>> ---------- Forwarded message ---------- >>>> From: neri-engineering <neri-engineering@protonmail.com> >>>> To: OpenSCAD general discussion Mailing-list <discuss@lists.openscad.org> >>>> Cc: >>>> Bcc: >>>> Date: Sat, 15 Oct 2022 00:50:23 +0000 >>>> Subject: [OpenSCAD] 100% ambient light source? Simple >>>> >>>> Before I explain the feature I'm looking for, I want to state that I am using OpenSCAD "to the limit" when it comes to generating computer animations of mechanical devices & assembly videos. OpenSCAD is very suitable for generating animations in many cases, because if you stay in that application you can handle dynamically generated parts without trying to "re-animate" them in a tool such as Blender. Springs that compress and decompress are a simple example of this. >>>> >>>> That being said, OpenSCAD has been extremely powerful for me in many cases, and I've avoided moving to a tool such as Blender altogether. >>>> >>>> However there is one simple case, where I actually want _LESS_ features than what OpenSCAD already has. This is related to the lighting model. I'm actually generating my computer animation frames, one by one, from the command line, by varying 't' and by varying the gimbal camera position in an intelligent manner, using cosine interpolations between various camera stopping points, etc. >>>> >>>> The need I have of OpenSCAD is to generate 2D cutaways and graphs. I have already done this with great success: >>>> >>>> https://odysee.com/@Neri_Engineering/profiles >>>> https://odysee.com/@Neri_Engineering/gimbal-cv-ver1-360-orange-green-calc-40-incident >>>> >>>> However for generation of such animations, which OpenSCAD is great at, and by using the "ortho" projection of course, it would be nice to have a lighting model which shines equally on every surface, at 100%, regardless of normal angle of surface with respect to light source(s). If you can imagine how horrendous this would look in the 3D view for example, you may have a toothed gear of one color where you can't make out the teeth at all, and you only see the silhouette of the entire gear in one solid color, in contrast to the background. Yes, it would look ugly. Yes, I understand why such an "ambient light" feature hasn't been implemented into OpenSCAD. I have no doubts about that. But, if you realize for a moment that the ambient light model is a simplification of the current lighting model, and that it would fill a certain need of generating 2D images, then you see that it would actually serve a great purpose. Especially considering that OpenSCAD is already so powerful at generating graphs & 2D images. >>>> >>>> In the example of the graph video above, the graph line is being drawn by spheres. Many of them. Yes, I could use cubes instead so that the color across the width of the line is more constant. But that is besides the point. The color on the visible face of the cube would still be affected by the angle that it makes with the light source(s). In these sorts of cases it makes more sense to have a 100% ambient light source, that lights up every surface to exactly that color which it's assigned to. >>>> >>>> In the 2D cross sectional diagrams (video above as well) the same problem - the color of the cross section is affected slightly by the angle of the surface in 3D. A simpler strategy would be to employ a 100% ambient lighting model. >>>> >>>> Furthermore a 100% ambient lighting model would not be difficult to implement. In fact it would likely be nothing more than taking away the feature of having the more intricate lighting model. I don't know how you would expose such a strange feature in the UI, though. Maybe it could be an Easter egg feature, or a hidden feature available only from command line. >>>> >>>> I am seeking to do this. I can find the area of code myself, and make the modifications necessary. But I don't know where to start looking. I am not looking for a workaround, e.g. by rotating the entire piece, along with the camera, to be aligned with the light source. In this case, I've decided, no workaround. Only implementation of the feature proposed. >>>> >>>> I was wondering if anyone has run across this problem before and/or where I would begin messing with the code, or maybe even it's a library that's outside of OpenSCAD. Also I'm a bit hesitant to set up the build environment for OpenSCAD, as it was installed in binary form via package system on Ubuntu 22. >>>> >>>> Respectfully, >>>> Nerius >>>> >>>> Sent with [Proton Mail](https://proton.me/) secure email. >>>> >>>> ---------- Forwarded message ---------- >>>> From: neri-engineering via Discuss <discuss@lists.openscad.org> >>>> To: OpenSCAD general discussion Mailing-list <discuss@lists.openscad.org> >>>> Cc: neri-engineering <neri-engineering@protonmail.com> >>>> Bcc: >>>> Date: Sat, 15 Oct 2022 00:50:23 +0000 >>>> Subject: [OpenSCAD] 100% ambient light source? Simple >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >> >> ---------- Forwarded message ---------- >> From: neri-engineering via Discuss <discuss@lists.openscad.org> >> To: OpenSCAD general discussion Mailing-list <discuss@lists.openscad.org> >> Cc: neri-engineering <neri-engineering@protonmail.com> >> Bcc: >> Date: Sat, 15 Oct 2022 14:01:40 +0000 >> Subject: [OpenSCAD] Re: 100% ambient light source? Simple >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org