 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
kurtz le pirate <kur### [at] free fr> wrote:
> ...
> I gather that you speak Perl too ?
> I feel less lonely...
</grin> sorry to disappoint, but Tcl is my "vice". but you are certainly not
alone and can take consolation :-) from the fact that a certain s/ware developer
in Australia too favours Perl. (and cannot understand my .. ignorance :-))
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> another installment in the long-running desire to have native stl support
> for POV-Ray. There was some insistence that .stl is a binary-only format, or
> that it would be difficult to adapt our mesh {} code to handle stl.
>
> So the point is that if the SDL and stl are virtually identical, then it ought
> to be fairly simple to add the ability _in source_ to #include "MyModel.stl"
>
This entire discussion interests me greatly! And it finally shook me out of my
lazy doldrums. (Real-life took over this summer-- work, plumbing problems, and
more dental problems.) Anyway...
Having ascii-STL-to-mesh (or mesh2) conversion built-in 'under-the-hood' would
be a great addition to POV-ray. But since v4.0 is still a long way off(?), some
kind of STL-to-POV-ray-SDL conversion script would be *most* welcome.
Kurtz's ascii-STL-to-mesh conversion-- vial a Perl script-- is an amazingly
successful piece of code, and very elegant. The excellent mesh result speaks for
itself. I don't know Perl, but I am *almost* convinced that a similar piece of
code could be written directly in POV's SDL, using #read and #write, because the
syntax used in typical STL files is so simple. The conversion code would
probably not be as elegant as Kurtz's, but that's a small price to pay.
Speaking of simplicity, I would argue that converting to a mesh (rather than
mesh2) would be the way to go-- as in Kurtz's result. It's much simpler to
implement, AND much simpler to edit afterwards, should the need arise. The mesh2
format and syntax is more 'abstract', and the docs' example of how it works (and
how to write it successfully) is lacking...although the necessary understanding
can be teased-out (with help from Wikipedia :-) -- at "triangle mesh", under
'index arrays'.) But I think that a simpler 'mesh' construct would be easier to
create from an STL file, when using #read/#write.
Mention was made here of possibly adding 'normals' to the resulting mesh
conversion-- which I take to mean, converting the triangles to 'smooth
triangles', so that curvy surfaces appear smooth in the POV-ray render, rather
than as the original STL flat-triangle 'facets'. But that may not produce the
intended effect for an *entire* model, as there could be smooth areas as well as
sharp angles and corners. Kurtz's "att.low.jpeg" example image shows such a
model. (The visual smoothing effect would depend on the triangle resolution, of
course.) The problem is that, in an STL file, there is no way to know which
triangles should be 'smoothed' and which should not; they are all just flat
facets.
An alternate scheme would be to slightly alter the vertex positions of all of
the flat triangles, to produce a somewhat similar smoothing effect in the POV
render...although I have no idea as to how that is accomplished, algorithm-wise.
------------
Kurtz's posted file package here has the original STL 'crate' model from
Thingaverse. That model actually has a few minor triangle (or normal?) flaws,
when seen in Meshmixer (and when 3-D-printed via CURA software; I printed a
small section of the crate, just to see.) I have noticed this in other
Thingaverse files as well. Apparently, no check is made of uploaded models
there, to make sure that the models are 'robust' and completely correct.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> Having ascii-STL-to-mesh (or mesh2) conversion built-in 'under-the-hood' would
> be a great addition to POV-ray. But since v4.0 is still a long way off(?), some
> kind of STL-to-POV-ray-SDL conversion script would be *most* welcome.
That said, if someone could provide a road map for what we need to do to write a
PATCH, then it could simply be added by unzipping a folder of the required
files, and ADDING the feature to the existing 3.7/3.8
>I don't know Perl, but I am *almost* convinced that a similar piece of
> code could be written directly in POV's SDL, using #read and #write, because the
> syntax used in typical STL files is so simple. The conversion code would
> probably not be as elegant as Kurtz's, but that's a small price to pay.
SDL sucks for this kind of thing, mostly because we don't have any way to read a
piece of data from a random file, determine what data type it is, and then run
conditional code.
All strings need to be quoted, we need commas, etc.
So, some sort of pre-processing script would need to be run first.
And if you're going to do that, why do it in SDL at all? Just do it in the
preprocessing language.
> Speaking of simplicity, I would argue that converting to a mesh (rather than
> mesh2) would be the way to go-- as in Kurtz's result. It's much simpler to
> implement, AND much simpler to edit afterwards, should the need arise. The mesh2
> format and syntax is more 'abstract', and the docs' example of how it works (and
> how to write it successfully) is lacking...although the necessary understanding
> can be teased-out (with help from Wikipedia :-) -- at "triangle mesh", under
> 'index arrays'.) But I think that a simpler 'mesh' construct would be easier to
> create from an STL file, when using #read/#write.
I have written both from scratch, and might have some code to assemble each
primitive from a collection of triangles kicking around somewhere.
It's basically a problem of connectivity. One can take the raw triangle data
and search for common vertices to see what triangles share edges, and build up
the data structure that way.
I'd favor conversion to a mesh, with the option of taking the resulting mesh and
making a mesh2 as an optional function to invoke separately.
Also no reason we couldn't just distribute such scripts in some sort of utility
directory with the distro.
> Mention was made here of possibly adding 'normals' to the resulting mesh
> conversion-- which I take to mean, converting the triangles to 'smooth
> triangles', so that curvy surfaces appear smooth in the POV-ray render, rather
> than as the original STL flat-triangle 'facets'. But that may not produce the
> intended effect for an *entire* model, as there could be smooth areas as well as
> sharp angles and corners. Kurtz's "att.low.jpeg" example image shows such a
> model. (The visual smoothing effect would depend on the triangle resolution, of
> course.) The problem is that, in an STL file, there is no way to know which
> triangles should be 'smoothed' and which should not; they are all just flat
> facets.
Very true, thus the continuing need for a modeler.
> An alternate scheme would be to slightly alter the vertex positions of all of
> the flat triangles, to produce a somewhat similar smoothing effect in the POV
> render...although I have no idea as to how that is accomplished, algorithm-wise.
Subdivision. Plus some interpolation code for the new vertices to follow the
smoothed edge.
> Kurtz's posted file package here has the original STL 'crate' model from
> Thingaverse. That model actually has a few minor triangle (or normal?) flaws,
> when seen in Meshmixer (and when 3-D-printed via CURA software; I printed a
> small section of the crate, just to see.) I have noticed this in other
> Thingaverse files as well. Apparently, no check is made of uploaded models
> there, to make sure that the models are 'robust' and completely correct.
Determining the correct normal direction for any given triangle can certainly be
challenging. It's probably the most difficult part of writing a modeling
software. I'd say you could probably run a check of all the neighboring
triangles and if all of the neighbors are within some given angular range of
each other, but the triangle you're checking is 180-range, then flip it.
Lots of articles and algorithms on the web covering this topic.
- bw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18/09/2025 15:09, Kenneth wrote:
>
> This entire discussion interests me greatly! And it finally shook me out of my
> lazy doldrums. (Real-life took over this summer-- work, plumbing problems, and
> more dental problems.) Anyway...
>
> Having ascii-STL-to-mesh (or mesh2) conversion built-in 'under-the-hood' would
> be a great addition to POV-ray. But since v4.0 is still a long way off(?), some
> kind of STL-to-POV-ray-SDL conversion script would be *most* welcome.
>
> Kurtz's ascii-STL-to-mesh conversion-- vial a Perl script-- is an amazingly
> successful piece of code, and very elegant. The excellent mesh result speaks for
> itself. I don't know Perl, but I am *almost* convinced that a similar piece of
> code could be written directly in POV's SDL, using #read and #write, because the
> syntax used in typical STL files is so simple. The conversion code would
> probably not be as elegant as Kurtz's, but that's a small price to pay.
>
> Speaking of simplicity, I would argue that converting to a mesh (rather than
> mesh2) would be the way to go-- as in Kurtz's result. It's much simpler to
> implement, AND much simpler to edit afterwards, should the need arise. The mesh2
> format and syntax is more 'abstract', and the docs' example of how it works (and
> how to write it successfully) is lacking...although the necessary understanding
> can be teased-out (with help from Wikipedia :-) -- at "triangle mesh", under
> 'index arrays'.) But I think that a simpler 'mesh' construct would be easier to
> create from an STL file, when using #read/#write.
>
> Mention was made here of possibly adding 'normals' to the resulting mesh
> conversion-- which I take to mean, converting the triangles to 'smooth
> triangles', so that curvy surfaces appear smooth in the POV-ray render, rather
> than as the original STL flat-triangle 'facets'. But that may not produce the
> intended effect for an *entire* model, as there could be smooth areas as well as
> sharp angles and corners. Kurtz's "att.low.jpeg" example image shows such a
> model. (The visual smoothing effect would depend on the triangle resolution, of
> course.) The problem is that, in an STL file, there is no way to know which
> triangles should be 'smoothed' and which should not; they are all just flat
> facets.
>
> An alternate scheme would be to slightly alter the vertex positions of all of
> the flat triangles, to produce a somewhat similar smoothing effect in the POV
> render...although I have no idea as to how that is accomplished, algorithm-wise.
> ------------
> Kurtz's posted file package here has the original STL 'crate' model from
> Thingaverse. That model actually has a few minor triangle (or normal?) flaws,
> when seen in Meshmixer (and when 3-D-printed via CURA software; I printed a
> small section of the crate, just to see.) I have noticed this in other
> Thingaverse files as well. Apparently, no check is made of uploaded models
> there, to make sure that the models are 'robust' and completely correct.
>
Thanks Kenneth.
I completely agree with your message and I would just like to add these
few points :
* Bad STL source, bad mesh.
* Adding 3D formats directly to POVRay is definitely a good thing, but
then for STL and not OBJ and not 3DS,...
* I understand, but I may be mistaken, that William F Pokorny is working
alone to improve and develop version 4 of POV, and that this is already
an enormous task.
* Adding support for other file formats would require even more work. Of
course, we could consider creating specific plugins for each format, but
POV's architecture does not allow for this. This is not a criticism, but
in 1986 the concept of add-ons did not exist.
Regards,
--
kurtz le pirate
compagnie de la banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/09/2025 02:32, Bald Eagle wrote:
> *** TRIGGER WARNING ***
> ...
I am following this discussion and asking myself: how many people will
use this converter(s) and how many conversions will they perform ? I
have a possible general solution for conversion frommost popular modern
formats (obj,fbx,glb,gltf,stl(a)) and can extend this list on
demand, but I'm not sure if it is worth doing.
At present time I am working with Three.js, making different web
applications (https://yesbird.online) and one of them is a viewer for
glaze samples, made for ceramists:
https://glazeview.yesbird.online/tc.html.
Adding export to mesh2 and interface modification is not too
complicated, but before starting, I would like to ask the community: do
we really need it ?
--
YB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
yesbird wrote:
> use this converter(s) and how many conversions will they perform ? I
Well, there's the ever-present risk-vs-benefit gamble.
Just look at the history of VHS vs beta, or any other product.
People ask me all the time:
Is it worth doing ANYTHING with a 30-year old raytracer?
> applications (https://yesbird.online) and one of them is a viewer for
> glaze samples, made for ceramists:
> https://glazeview.yesbird.online/tc.html.
This is probably beautiful.
I see the pottery and glaze samples, but the rest of it doesn't seem to work
with Brave browser. Probably need to update my browser, but I'm using Win7
anyway...
I'll check with my Win 11 <barf> laptop, and at some point, use the linux Mint
side as well.
> Adding export to mesh2 and interface modification is not too
> complicated, but before starting, I would like to ask the community: do
> we really need it ?
The only speculation that I have to offer is: If you build it, they will come.
Grab a bunch of models off of Thingaverse, export them to include files with
inside_vector already defined, and then see if people play.
Plenty of people in the world (still) ask, "what do I need to learn algebra
for?"
People once asked "Why would anyone use the Fourier transform?"
Look at what Ton is doing. People might not have the patience for that, but if
a model of the part they wanted already existed...
If I learn c++ so I can unravel all of the source code for the solid/surface of
revolution, and essentially build an SDL modeler for sor {} - will anyone use
it? Who uses sor {} anyway?
I have no idea. But I'm learning.
I can tell you that if we expanded our user base, and offered an inbuilt
stl-to-mesh conversion, you bet people would use it! Probably every day.
I think we might lose a lot of the character of past hand-crafted scenes, but
you might get people to use POV-Ray to make a scene - any scene at all - if they
could just #include "MyPart.inc" and raytrace it within minutes.
Like I've pointed out in the past. We need advertising and recruitment.
And we need development.
And those two things need to happen simultaneously, so they can build on each
other. Chicken & egg.
I love what I've seen done with Three.js, and it would be great to get more
updates on what you've been doing and how :)
- bw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20/09/2025 17:28, Bald Eagle wrote:
> This is probably beautiful.
> I see the pottery and glaze samples, but the rest of it doesn't seem to work
> with Brave browser. Probably need to update my browser, but I'm using Win7
> anyway...
Try this link to test:
https://webglreport.com
The only Three.js necessary requirement is WebGL support.
> The only speculation that I have to offer is: If you build it, they will come.
> Grab a bunch of models off of Thingaverse, export them to include files with
> inside_vector already defined, and then see if people play.
> ...
> Look at what Ton is doing. People might not have the patience for that, but if
> a model of the part they wanted already existed...
> ...
> I can tell you that if we expanded our user base, and offered an inbuilt
> stl-to-mesh conversion, you bet people would use it! Probably every day.
> I think we might lose a lot of the character of past hand-crafted scenes, but
> you might get people to use POV-Ray to make a scene - any scene at all - if they
> could just #include "MyPart.inc" and raytrace it within minutes.
I am in doubt also, because people already have a free Blender for
modelling which supports rendering with POV-Ray. Why not to use it
instead of leaning complicated and outdated SDL ? SDL is good for math
experiments, for example, but modelling is too painful with it.
>
> If I learn c++ so I can unravel all of the source code for the solid/surface of
> revolution, and essentially build an SDL modeler for sor {} - will anyone use
> it? Who uses sor {} anyway?
>
> I have no idea. But I'm learning.
Why not to try JS with Three.js instead ? :)
Much more easy, perspective, and highly demanded -
"Close to the Edge" of modern technology :).
>
> Like I've pointed out in the past. We need advertising and recruitment.
> And we need development.
> And those two things need to happen simultaneously, so they can build on each
> other. Chicken & egg.
Ouroboros, maybe :).
>
> I love what I've seen done with Three.js, and it would be great to get more
> updates on what you've been doing and how :)
I am planning to concentrate on a parametric surfaces this autumn/winter
season: https://mathview.yesbird.online/
Viewer itself is ready, now it's time to extend surfaces collection.
Wish you good luck with learning and technological discoveries.
--
YB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20/09/2025 15:46, yesbird wrote:
> I am following this discussion and asking myself: how many people will
> use this converter(s) and how many conversions will they perform ? I
> have a possible general solution for conversion frommost popular modern
> formats (obj,fbx,glb,gltf,stl(a)) and can extend this list on
> demand, but I'm not sure if it is worth doing.
Just a joke : how many people will use your solution and how many
conversions will they generate ?
> At present time I am working with Three.js, making different web
> applications (https://yesbird.online) and one of them is a viewer for
> glaze samples, made for ceramists:
> https://glazeview.yesbird.online/tc.html.
Three.js, JavaScript ... yet another new language to learn that isn't
designed for creating computer-generated images and which is not that
easy to learn.
... and, for *me*, javascript is disable in my browser because here is
an increasing number of ways for JavaScript to be used maliciously.
JavaScript based attacks such as Cross Site Scripting and Click Jacking
rely on JavaScript and can cause the security to be compromised. There
are an increasing number of security minded people who do not just let
JavaScript run on every single page they visit to decrease the chances
of these attacks.
I might be paranoid, but it is only my position.
--
kurtz le pirate
compagnie de la banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20/09/2025 20:38, kurtz le pirate wrote:
>
> Just a joke : how many people will use your solution and how many
> conversions will they generate ?
>
Exactly, this is the reason for my doubts about writing it.
>
> Three.js, JavaScript ... yet another new language to learn that isn't
> designed for creating computer-generated images and which is not that
> easy to learn.
I guess that JavaScript is one of the easiest languages to learn, at
least much more easy than Perl, for example. Yes, image generation
features are not a part of it, but they are containing in libraries.
At the same time WebGL (and now WebGPU) approach(s) gives a lot of
advantages: easy access to applications with browsers, interactivity,
using the user's GPU for rendering ... This is the reason why I switched
to Three.js from POV-Ray while still loving it.
>
> ... and, for *me*, javascript is disable in my browser because here is
> an increasing number of ways for JavaScript to be used maliciously.
> JavaScript based attacks such as Cross Site Scripting and Click Jacking
> rely on JavaScript and can cause the security to be compromised. There
> are an increasing number of security minded people who do not just let
> JavaScript run on every single page they visit to decrease the chances
> of these attacks.
>
> I might be paranoid, but it is only my position.
>
No, I don't think so, but at modern state of internet huge part of the
sites can't function without JS - can't stop the progress ).
--
YB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20/09/2025 16:46, yesbird wrote:
> Adding export to mesh2 and interface modification is not too
> complicated, but before starting, I would like to ask the community: do
> we really need it ?
And so, "silence is golden" :). Now I am completely sure that POV-Ray is
self-sufficient and doesn't need any external sources of geometry.
Thanks for saving my time and effort :).
--
YB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
