 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
yesbird wrote:
> On 08/10/2025 19:10, kurtz le pirate wrote:
> > Sure ! A zip file with the OBJ file and my INC file.
>
> Thanks, merging is the reason, I see a lot of duplicates here:
> grep -w v pingouin.obj | tail -n 20
> v 0.023851 0.00175495 0.0374573
> v 0.023851 0.00175495 0.0374573
> v 0.023851 0.00175495 0.0374573
> (etc.)
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.
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?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
> 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 :)
--
YB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
kurtz le pirate <kur### [at] freefr> wrote:
>
> I think that for very large meshes, the size of the converted file with
> 18 digits increases enormously without providing any additional precision.
>
> 4 or 6 digits should suffice and would reduce the size by more than four
> times (18/4=4.5).
>
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.
HOWEVER, I am now thinking that it needs to be a 'dynamic' value-- based on the
number of triangles (or vertices) in the original file (whether .stl or .obj or
whatever type.)
Some files have a low-triangle count, others very high. As the number of
triangles increases, it usually means that they are smaller (for a given-size
object), to produce finer detail-- and thus require more precision in their
values. Otherwise, a 4-to-6 significant digit conversion process might create
unwanted duplicate values by truncating or rounding important digits. Here's an
example of my thinking:
an original float value in a LOW-triangle-count model:
69.5746344739 // probably overkill, since the triangles themselves are larger in
relation to the overall object. This could be reduced/rounded to 4 or 5 digits,
IMO, and still produce a perfectly adequate final model.
an original float value in a HIGH-triangle-count model:
69.5746344739 // all of those digits would probably be necessary, to prevent
duplicates due to rounding.
Then there are the middle cases between 'low' and 'high', of course.
I don't have a formula for creating such a dynamically-changing number of
significant digits-- because it is not yet clear as to what constitutes a low
triangle-count vs a higher one!-- but the idea might be worth pursuing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
