 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/10/2025 03:21, Kenneth wrote:
> In my own POV-ray-only stl-to-mesh converter-- not yet posted ;-) -- I came to
> the same conclusion: that 4 or 5 digits were enough, and that more were simply
> overkill. In my experience, some models' float values are written with much more
> precision than is necessary...
Many thanks for sharing the results of your investigation - there is a
space for analysis here. Necessary precision is really dependent on a
model's scale. Current release has 6 digits, let's try to test it. I
guess, the file size is not a serious limitation, so increasing to 8-10
is possible.
--
YB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
yesbird wrote:
> Necessary precision is really dependent on a
> model's scale. Current release has 6 digits, let's try to test it. I
> guess, the file size is not a serious limitation, so increasing to 8-10
> is possible.
Just a cautionary observation.
It's difficult or impossible to predict the end user's use of a model or the
precision they need.
Is it possible to have the user select the desired precision before conversion?
Can a file size be estimated based on the number of vertices and the selected
precision?
Hard-coding magic numbers doesn't seem like the way to go if it isn't to
difficult to make everything adjustable.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/10/2025 04:23, Bald Eagle wrote:
> Hard-coding magic numbers doesn't seem like the way to go if it isn't to
> difficult to make everything adjustable.
Not sure that this is the most important thing to do now,
but could you give an examples of the modern systems with adjustable
precision and method they use to calculate it ?
I see that C4D gives 14 digits (attached).
--
YB
Post a reply to this message
Attachments:
Download 'cube_c4d.obj.txt' (1 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
yesbird wrote:
> Not sure that this is the most important thing to do now,
> but could you give an examples of the modern systems with adjustable
> precision and method they use to calculate it ?
(I wasn't making a value judgement about its importance or timeliness, I was
just making an observation.)
I guess various packages have "tolerance" and "decimation error" settings.
https://help.autodesk.com/view/PWRS/2025/ENU/?guid=GUID-465F277C-E3AE-4D83-B14E-0832137FCF4D
https://www.open3d.org/docs/latest/python_api/open3d.t.geometry.TriangleMesh.html
Simplify mesh by Threshold: This is an easy way to reduce the file size of a
mesh for manufacturing. This block will create the mesh with the least amount of
faces. A good starting point for the threshold is 1/4 to 1/8 of the
manufacturing tolerance.
Simplify mesh by Amount: This block generates a mesh that is smaller than the
original based on the specified amount. For example, a value of 0.9 will create
a mesh with 90% fewer faces, and as a result 90% smaller file size.
https://www.ntop.com/resources/blog/meshing-in-fea-cfd-manufacturing/
https://help.altair.com/inspire/en_us/topics/implicit/visualization_r.htm#:~:text=This%20is%20usually%20seen%20in,doing
%20this%20is%20shown%20below.
https://support.carveco.com/hc/en-gb/articles/19604059276316-3D-Design-Creating-Triangle-Mesh-For-Exporting#:~:text=The
%20two%20settings%20work%20hand,tolerance%20low%20and%20optimisation%20enabled.
https://nexus.hexagon.com/documentationcenter/en-US/bundle/VISI_2025_2_FLOW_Online_Help/page/Content/CadMeshTolerance.h
tml
Lots of search results for "triangle mesh decimation"
This would probably be the biggest file-size optimizer, because there's no
reason to have a cube with 10,000 coplanar triangle faces when 2 would
indistinguishably do the job - probably with more accuracy and fewer artifacts
to due to floating point noise.
How to calculate it?
Rounding and truncation, I would imagine.
> I see that C4D gives 14 digits (attached).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/10/2025 05:17, Bald Eagle wrote:
> yesbird wrote:
>
> I guess various packages have "tolerance" and "decimation error" settings...
...
> How to calculate it?
> Rounding and truncation, I would imagine.
Thank you for parsing Google search results, but I do not see a
concrete formula for precision calculation :).
Long things short: Paul Bourke after reviewing the first version of
converter was wondering why the precision of the data was changed
(increased) on conversion and suggested leaving it as it was in the
input file. I guess this makes sense, because we don't recalculate
coordinates, but simply repack them from one format to another.
In the next release I will follow his advice.
--
YB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Your materials are even improving, and already looked very good !
Please I insist, that it's a bad strategy to despise phones because as far as I
know, POV is still as of today the only 3D renderer working on Android through
its Termux port. (and no it does not overheat!)
and instead of Tik Tok the youths could have something so much better to do with
them ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/10/2025 23:22, Kenneth wrote:
> "Kenneth" <kdw### [at] gmail com> wrote:
>>
>> Does your analysis of Kurtz's file indicate duplicate *triangles*, or just
>> duplicate vertices? Kurtz is converting his STL file to plain mesh AFAIU (not
>> mesh2)--
>
> My apologies; I was confusing your OBJ file discussion with STL file conversion.
>
>
Indeed, but that's okay.
And yes, I also have an obj2pov, stl2pov, eps2pov, scripts.
--
kurtz le pirate
compagnie de la banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/10/2025 23:41, yesbird wrote:
> On 09/10/2025 00:03, Kenneth wrote:
>> Does your analysis of Kurtz's file indicate duplicate *triangles*, or
>> just
>> duplicate vertices? Kurtz is converting his STL file to plain mesh
>> AFAIU (not
>> mesh2)-- and in such files there are necessarily many duplicate
>> vertices, since
>> they are shared among some triangles. I'm guessing that your own mesh2
>> conversion code 'consolidates' those somehow-- resulting in fewer
>> vertices
>> overall.
>>
>> My apologies; I was confusing your OBJ file discussion with STL file
>> conversion.
>
> I only answered the Kurtz's question about difference in of vertices in
> our results. There is no *.inc file in Kurtz's zip, so I grepped obj.
Sorry, I forgot the INC file.
Here now ;)
>> If so, is this consolidation or merging one of the 'efficiency'
>> benefits of
>> POV-ray's own mesh2 construct, or is it an extra operation that you
>> added to
>> your own conversion code?
>
> My conversion process is following:
> 1. Calling OBJLoader() from Three.js library to load meshes into scene.
>
> 2. Call standard Three.js mergeVertices() method for each mesh on load
> to build vertices index, that completely excludes duplicates.
>
> 3. Call my POVExporter(), which traverses scene, selects meshes and
> saves data to model.ini as mesh2.
>
> Very simple :)
--
kurtz le pirate
compagnie de la banquise
Post a reply to this message
Attachments:
Download 'pingouin.inc.zip' (873 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/10/2025 10:06, Mr wrote:
> Your materials are even improving, and already looked very good !
Thanks for kind words, but still there is a space for improvement.
I hope more experienced POV-Ray community will help me to do that.
> Please I insist, that it's a bad strategy to despise phones because as far as I
> know, POV is still as of today the only 3D renderer working on Android through
> its Termux port. (and no it does not overheat!)
> and instead of Tik Tok the youths could have something so much better to do with
> them ;-)
It's a very unexpected, but interesting idea, I will consider it in
future, although supporting phones is painful because of too many
different resolutions. Right now I would like to concentrate on main
functionality and extending the materials library.
Btw, I am almost ready to make a proposal about integration to Blender's
developer, you, mentioned earlier, and will write it today. Hope for
productive collaboration.
PS: Zoomers preferes games, vintage SDL is not for them ).
--
YB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
yesbird wrote:
> On 09/10/2025 10:06, Mr wrote:
> > Your materials are even improving, and already looked very good !
>
> Thanks for kind words, but still there is a space for improvement.
> I hope more experienced POV-Ray community will help me to do that.
>
> > Please I insist, that it's a bad strategy to despise phones because as far as I
> > know, POV is still as of today the only 3D renderer working on Android through
> > its Termux port. (and no it does not overheat!)
> > and instead of Tik Tok the youths could have something so much better to do with
> > them ;-)
>
> It's a very unexpected, but interesting idea, I will consider it in
> future, although supporting phones is painful because of too many
> different resolutions. Right now I would like to concentrate on main
> functionality and extending the materials library.
>
> Btw, I am almost ready to make a proposal about integration to Blender's
> developer, you, mentioned earlier, and will write it today. Hope for
> productive collaboration.
>
> PS: Zoomers preferes games, vintage SDL is not for them ).
> --
> YB
I sent you an email.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
