 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> STL may exist in binary form (although I see no good reason for that.
Binary stl files are much smaller in size.
Otherwise as easy to parse as the ascii readable variant.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
