On 05/10/2025 14:58, yesbird wrote:
> 
> Thanks for feedback, could you please provide a little bit more
> details - why can't you convert them ? And who else can't ?
> Please send me your OBJ and content of _console_ tab (F12).

Hum ... After another attempt today, my file loaded correctly and my 
pingoin appears correctly.

Have you noticed any improvements ?


Another thing about my converter. I find 18,531 vertices, while you only 
have 952.


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).




Good job ;)


> The project is in beta state, so debug information is highly
> appreciated.


-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

On 08/10/2025 18:29, kurtz le pirate wrote:
> Have you noticed any improvements ?

Yes, I am working hard and updating it daily, fixing the bugs and
implementing new features. Now working on material library and improving
studio environment.

> Another thing about my converter. I find 18,531 vertices, while you only 
> have 952.

I do merging on load, maybe this is the reason. Could you please send me
your file for testing ? Good bug report is the half of a successful fix
:).

> 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).

Agree with you and have already been included it in my TODO list.

> 
> Good job ;)

Thanks for the kind words :).
--
YB

Post a reply to this message

On 08/10/2025 17:58, yesbird wrote:
> On 08/10/2025 18:29, kurtz le pirate wrote:
>> Have you noticed any improvements ?
> 
> Yes, I am working hard and updating it daily, fixing the bugs and
> implementing new features. Now working on material library and improving
> studio environment.
> 
>> Another thing about my converter. I find 18,531 vertices, while you 
>> only have 952.
> 
> I do merging on load, maybe this is the reason. Could you please send me
> your file for testing ? Good bug report is the half of a successful fix
> :).


Sure ! A zip file with the OBJ file and my INC file.


>> 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).
> 
> Agree with you and have already been included it in my TODO list.
> 
>>
>> Good job ;)
> 
> Thanks for the kind words :).
> -- 
> YB
> 
> 





-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

Attachments:
Download 'pingouin.zip' (746 KB)

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
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
v 0.023851 0.00175495 0.0374573
-------------------------------

PS: Attached pingouin inspired by Terminator-2 ).
-- 
YB

Post a reply to this message

Attachments:
Download 'pingouin.png' (219 KB)

Preview of image 'pingouin.png'

On 08/10/2025 20:00, 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 ...

Z-Brush also report about unused vertices, please find optimized version
in attachment.
-- 
YB

Post a reply to this message

Attachments:
Download 'pingouin_cleaned.zip' (458 KB) Download 'pingouin_zb.png' (351 KB)

Preview of image 'pingouin_zb.png'

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] gmailcom> 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