Re: 100% ambient light source? Simple
It only renders the original primitives, which are polygons like cubes and
cylinders and user supplied polygons. So if there is a new vertex created
by a union or difference, etc it doesn't know about it. Not sure if
Gouraud shading
the primitives before the CSG ops are done by pixel buffer tricks
would work. I think it would break the CSG ops but after you just have
pixels and no vertices. I may be wrong but I think the pixel values are
used to represent the id of objects and then replaced by colours
afterwards. That is why the shading is flat, I think.
I suspect that you need the finished CGAL render, which has all the
vertices, to have something you could shade and add textures to.
On Sat, 15 Oct 2022 at 16:30, 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 15:29:29 +0000
Subject: [OpenSCAD] Re: 100% ambient light source? Simple
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
---------- 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 15:29:29 +0000
Subject: [OpenSCAD] Re: 100% ambient light source? Simple
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I have realized my mistake and I'm sorry for wasting your time on this subject of Gouraud shading.
Even if Gouraud shading were possible, it would not be desired in the general case. Take for example, on occasion I do cylinders having fn of 6 to create hex rods. It's meant to be a hex rod with sharp edges and well-defined flat faces. A Gouraud application would make this thing look like an ugly cylinder-like blob.
If you apply Gouraud to a cube which is meant to be a cube you'd also get an ugly blob.
In general the types of things designed with OpenSCAD will have sharp edges. So Gouraud shading not really applicable.
Doing different shadings on a case-by-case basis (or even edge-by-edge basis) would be totally hacky and unreasonable, not worth the while.
Phong shading is a better algorithm in my opinion (than is Gouraud), but it add such a level of complexity that it's better left for tools such as Blender - adn besides it applies mostly to point light sources and not directional light sources (it applies to candles and lightbulbs and not sunlight). OpenCSG uses directional light sources of "parallel light rays", e.g. like the sun.
Again, this has been a roundabout discussion and now I realize how premature and erroneous my idea was.
To get back to the original idea, I think an option, or environment variable, in OpenCSG to do 100% ambient lighting for the entire scene would be a nice-to-have for generating 2D cutaways and graphs.
Sent with Proton Mail secure email.
------- Original Message -------
On Saturday, October 15th, 2022 at 10:45 AM, nop head nop.head@gmail.com wrote:
It only renders the original primitives, which are polygons like cubes and cylinders and user supplied polygons. So if there is a new vertex created by a union or difference, etc it doesn't know about it. Not sure if Gouraud shading the primitives before the CSG ops are done by pixel buffer tricks would work. I think it would break the CSG ops but after you just have pixels and no vertices. I may be wrong but I think the pixel values are used to represent the id of objects and then replaced by colours afterwards. That is why the shading is flat, I think.
I suspect that you need the finished CGAL render, which has all the vertices, to have something you could shade and add textures to.
On Sat, 15 Oct 2022 at 16:30, 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 15:29:29 +0000
Subject: [OpenSCAD] Re: 100% ambient light source? Simple
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 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 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 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
---------- 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 15:29:29 +0000
Subject: [OpenSCAD] Re: 100% ambient light source? Simple
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenCSG only renders into the z-buffer and does not touch the pixels in the color buffer. Then, it is OpenSCAD's turn to render the same geometry again, using a special depth function to only write pixels with the same z-value as in the z-buffer already, but with whatever lighting and shading that is desired.
So the implementation of this request is entirely within OpenSCAD. Probably it suffices to find a call to glEnable(GL_LIGHTING) and change it to glDisable(GL_LIGHTING). Or, the programmable shaders that may be used to render the geometry must be changed.
Florian Kirsch
On Sat, 15 Oct 2022 at 16:30, 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 15:29:29 +0000
Subject: [OpenSCAD] Re: 100% ambient light source? Simple 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 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 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-incidentHowever 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 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---------- 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 15:29:29 +0000
Subject: [OpenSCAD] Re: 100% ambient light source? Simple
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
_______________________________________________ OpenSCAD mailing list To unsubscribe send an email to discuss-leave@lists.openscad.org