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

yesbird wrote:
> On 09/09/2025 02:32, Bald Eagle wrote:
> > *** TRIGGER WARNING ***
> > ...

> use this converter(s) and how many conversions will they perform ?
[snip]
>I would like to ask the community: do we really need it ?

I would answer YES, for several reasons:

First and foremost, POV-ray is a great raytracing RENDERER. As B.E. mentioned,
there are so MANY STL models out there, that could be beautifully rendered by us
as-is (even if the mesh conversion retained only the un-smoothed
flat-faceted-triangles); or as part of a CSG construction (with the addition of
an inside vector to the converted mesh).

And a favorite technique of my own is to turn an object (even a mesh) into an
object pattern, then into a function, and to use that to create an isosurface
(although this has some limitations)-- but which can then be altered with
interesting distortions like warp{turbulence...}, fnoise_3D, etc.-- a kind of
shape-alteration that cannot be done any other way. Some STL models I've seen
would be great for that.

It's probably true that the majority of available STL models are in binary form
rather than as ascii files; but Kurtz found an online binary-to-ascii conversion
process, and his mesh 'crate' result is excellent. So that's not a bottleneck.

As to whether or not there are a limited number of us who would benefit from
such a converter, I would argue that there are plenty of *existing* features in
POV-ray that have historically been used by only a few people (including me!)--
but that does not negate their importance or usefulness; they are there IF we
need them. (Personally, I still feel that I have only 'scratched the surface' of
what POV-ray is capable of, with its many features and include files, and even
with its CSG modeling capabilities.)

To be able to use and render STL models would be a great addition to all of the
other features...and might even open up POV-ray to people who might otherwise be
hesitant to learn its SDL.

Post a reply to this message

On 23.09.2025 20:06, Kenneth wrote:

> First and foremost, POV-ray is a great raytracing RENDERER. As B.E. mentioned,
> there are so MANY STL models out there, that could be beautifully rendered by us
> as-is (even if the mesh conversion retained only the un-smoothed
> flat-faceted-triangles); or as part of a CSG construction (with the addition of
> an inside vector to the converted mesh).

STL models, by their nature, must have all sides defined (which makes 
STLs exported by my img2mesh twice as big as POVs, since POVs only have 
a top side). So I guess inside vector may be any.

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> And a favorite technique of my own is to turn an object (even a mesh) into an
> object pattern, then into a function, and to use that to create an isosurface
> (although this has some limitations)-- but which can then be altered with
> interesting distortions like warp{turbulence...}, fnoise_3D, etc.-- a kind of
> shape-alteration that cannot be done any other way. Some STL models I've seen
> would be great for that.

Perhaps you could also check out

https://www.infradead.org/~wmp/macro_meshrelief.html

or touch base with Bill Pragnell about how best to use functions to distort your
meshes directly.

Once you learn how to remap space, you will have an amazing toybox at your
disposal.

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > And a favorite technique of my own is to turn an object (even a mesh) into an
> > object pattern, then into a function, and to use that to create an isosurface
> > (although this has some limitations)-- but which can then be altered with
> > interesting distortions like warp{turbulence...}, fnoise_3D, etc.
>
> touch base with Bill Pragnell about how best to use functions to distort your
> meshes directly.

Yes, meshes could be distorted in other ways than by my object-pattern idea; but
I mostly use CSG models with the process. It just happens that meshes work with
it too.

The downside of the process is a lighting problem: The resulting isosurface does
NOT respond to lighting well, and looks very odd-- the surface normals are
*quite* strange, to say the least, probably because the object pattern was never
made to be used this way.  So I texture the final iso using an ambient 1
finish...which sounds very limiting... but I also use Rune's old ILLUSION.INC to
apply the texture (like 'texture baking' in this case), which solves the
lighting problem quite nicely. I've been meaning to post about this scheme for
quite awhile, as the results are rather extraordinary, IMHO. I hope to get
around to it soon...

Post a reply to this message

yesbird wrote:
> 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.

Similar to how Le Forgeron states in his sig:
"Just because nobody complains does not mean all parachutes are perfect."

I would follow that up with a similar:
"Just because no one got back to you, doesn't mean no one wants the feature."

There are, as I understand things, many people who download and use POV-Ray
academically and professionally, yet we never see them here on the forums.
People hang out in weird places on the internet, or just have no interest in
participating in the forums.
Over the years, I have tried to scour the internet and post links to instances
where people have, or are currently using POV-Ray - with links to articles,
websites, and sometimes name + academic position.
There is also the phenomenon that this forum will be radio silent for 2 weeks or
more, and then a sudden flurry of activity will occur all at once.

So asking here is not the best way to receive a meaningful answer.

> Thanks for saving my time and effort :).

I was just suggesting it.
I know you have a lot of other activities that take up your time and attention.

- bw

Post a reply to this message

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 23.09.2025 20:06, Kenneth wrote:
>
> ..or as part of a CSG construction (with the addition of
> > an inside vector to the converted mesh).
>
> STL models, by their nature, must have all sides defined (which makes
> STLs exported by my img2mesh twice as big as POVs, since POVs only have
> a top side). So I guess inside vector may be any.
>
I usually use a single  inside_vector <1,1,1>  in my meshes, so that its vector
direction is not pointed exactly toward any of the x,y,z axes or planes. This
helps prevent subtle CSG errors that have been known to occur at times. <1,1,1>
is my generic 'safety measure'. ;-)

Post a reply to this message