 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/09/2025 20:26, ingo wrote:
> A quicky in Nim, not much tested:
>
> ---%<------%<------%<------%<---
>
> [snip]
>
> ---%<------%<------%<------%<---
>
> ingo
I don't know Nim very well, but the code is interesting.
Even Yoda agrees ;)
--
kurtz le pirate
compagnie de la banquise
Post a reply to this message
Attachments:
Download 'test_yoda.jpeg.jpg' (233 KB)
Preview of image 'test_yoda.jpeg.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
kurtz le pirate <kur### [at] free fr> wrote:
>
>
> I don't know Nim very well, but the code is interesting.
> Even Yoda agrees ;)
Hahaha. Well, for Yoda then, one that reads binary stl, rather untested again,
---%<------%<------%<------%<---
import std/[streams,math, sequtils, strformat]
type
Vec3 = array[3, float]
Face = array[3, int]
proc vec3(x,y,z: float): Vec3 = [x,y,z]
proc `+`(a,b: Vec3): Vec3 = [a[0]+b[0], a[1]+b[1], a[2]+b[2]]
proc `/`(a: Vec3, s: float): Vec3 = [a[0]/s, a[1]/s, a[2]/s]
proc dot(a,b: Vec3): float = a[0]*b[0]+a[1]*b[1]+a[2]*b[2]
proc length(v: Vec3): float = sqrt(dot(v,v))
proc normalize(v: Vec3): Vec3 =
let l = length(v)
if l > 1e-9: v / l else: vec3(0,1,0)
proc readVec3(s: Stream): Vec3 =
result[0] = s.readFloat32()
result[1] = s.readFloat32()
result[2] = s.readFloat32()
proc loadBinarySTL(path: string): (seq[Vec3], seq[Face], seq[Vec3]) =
## Parse binary STL, returning vertices, faces, and per-face normals
var f = newFileStream(path, fmRead)
defer: f.close()
discard f.readStr(80) # skip header
let triCount = f.readUint32()
var verts: seq[Vec3] = @[]
var faces: seq[Face] = @[]
var faceNorms: seq[Vec3] = @[]
for i in 0..<int(triCount):
let n = readVec3(f) # face normal
let v1 = readVec3(f)
let v2 = readVec3(f)
let v3 = readVec3(f)
discard f.readUint16() # attribute byte count
let base = verts.len
verts.add(v1)
verts.add(v2)
verts.add(v3)
faces.add([base, base+1, base+2])
faceNorms.add(normalize(n))
return (verts, faces, faceNorms)
# adjecent vertises
proc vertexToFaces(faces: seq[Face], vertexCount: int): seq[seq[int]] =
result = newSeqWith(vertexCount, newSeq[int]())
for fi, f in faces:
for vi in f:
result[vi].add(fi)
# Vertex normals by averaging face normals
proc computeVertexNormals(vertexCount: int, faceNormals: seq[Vec3], v2f:
seq[seq[int]]): seq[Vec3] =
result = newSeqWith(vertexCount, vec3(0,0,0))
for vi in 0..<vertexCount:
var accum = vec3(0,0,0)
for fi in v2f[vi]:
accum = accum + faceNormals[fi]
result[vi] = normalize(accum)
proc mesh2ToString(verts: seq[Vec3], faces: seq[Face], normals: seq[Vec3]):
string =
var sb = newStringOfCap(verts.len * 100)
sb.add("mesh2 {\n")
sb.add(" vertex_vectors {\n")
sb.add(" " & $verts.len & ",\n")
for v in verts: sb.add(&" <{v[0]}, {v[1]}, {v[2]}>,\n")
sb.add(" }\n")
sb.add(" normal_vectors {\n")
sb.add(" " & $normals.len & ",\n")
for n in normals: sb.add(&" <{n[0]}, {n[1]}, {n[2]}>,\n")
sb.add(" }\n")
sb.add(" face_indices {\n")
sb.add(" " & $faces.len & ",\n")
for f in faces: sb.add(&" <{f[0]}, {f[1]}, {f[2]}>,\n")
sb.add(" }\n")
sb.add("}\n")
result = sb
proc writeMesh2(path: string, verts: seq[Vec3], faces: seq[Face], normals:
seq[Vec3]) =
writeFile(path, mesh2ToString(verts, faces, normals))
when isMainModule:
let (verts, faces, faceNorms) = loadBinarySTL("model.stl")
let v2f = vertexToFaces(faces, verts.len)
let vertexNorms = computeVertexNormals(verts.len, faceNorms, v2f)
writeMesh2("model.inc", verts, faces, vertexNorms)
echo "Binary STL converted to POV-Ray mesh2."
---%<------%<------%<------%<---
They realy should have/get a decent command line interface...
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
kurtz le pirate <kur### [at] freefr> wrote:
> On 10/09/2025 17:11, kurtz le pirate wrote:
> > The wiki page shows that the structure is very simple, and I think Perl*
> > is a very good candidate for this.
>
> Finally, I spent an hour and here is my first result ;)
> ...
thanks, it helped me to find a bug; two, if I count your code </grin>.
according to the Wikipedia page, "An ASCII STL file begins with the line:
solid name
where name is an optional string (though if name is omitted there must still be
a space after solid, for compatibility with some software).
<en.wikipedia.org/wiki/STL_(file_format)>
my code got tripped up by the missing space in the data.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 15/09/2025 16:32, jr wrote:
>> ...
>
> thanks, it helped me to find a bug; two, if I count your code </grin>.
>
Glad to be of help.
I gather that you speak Perl too ?
I feel less lonely...
--
kurtz le pirate
compagnie de la banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
kurtz le pirate <kur### [at] freefr> 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
|
|
| |
| |
|
|
|
|
| |
|
|
