 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
I *just* noticed something odd about your online STL-to-mesh2 conversion
process. (I should have mentioned it before now, but was too busy working on my
own converter; my apologies.)
It seems that the resulting mesh2 triangles are facing 'inside out'-- the
insides face outside and vice versa. See my attached render of an STL (binary)
file that I uploaded to your page and converted tonight.
In the converted mesh2 file, I first deleted your union{...} and material{...}
at the end, then rendered the mesh2 with my own textures: A regular texture AND
an interior_texture.
However, this is NOT a fault of your conversion process: I noticed the same
behavior while working on my own POV-ray STL-to-mesh converter. The 3 vertices
in each STL triangle are apparently written the opposite way 'around the clock'
-- opposite chirality-- according to how *POV-ray* expects them. I had to fix
this in my own code, simply by swapping the triangles' 3rd point for the 1st.
Like:
an original STL triangle:
triangle{<1,2,3>, <4,5,6>, <7,8,9>}
for correct POV-ray rendering:
triangle{<7,8,9>, <4,5,6>, <1,2,3>}
STL files (and 3D printers) are apparently standardized for a 3-vertex chirality
that is opposite to POV-ray's own triangle-rendering scheme.
Post a reply to this message
Attachments:
Download 'triangles_inside_out_kw_10_10_25.jpg' (20 KB)
Preview of image 'triangles_inside_out_kw_10_10_25.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/10/2025 13:22, Kenneth wrote:
> I *just* noticed something odd about your online STL-to-mesh2 conversion
> process. (I should have mentioned it before now, but was too busy working on my
> own converter; my apologies.)
> ...
It's interesting, thank you for detailed feedback, I will check it and
post the results here. Testing is highly appreciated at this state of
the project.
--
YB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> However, this is NOT a fault of your conversion process: I noticed the same
> behavior while working on my own POV-ray STL-to-mesh converter. The 3 vertices
> in each STL triangle are apparently written the opposite way 'around the clock'
> -- opposite chirality-- according to how *POV-ray* expects them. I had to fix
> this in my own code, simply by swapping the triangles' 3rd point for the 1st.
> Like:
>
> an original STL triangle:
> triangle{<1,2,3>, <4,5,6>, <7,8,9>}
>
> for correct POV-ray rendering:
> triangle{<7,8,9>, <4,5,6>, <1,2,3>}
>
> STL files (and 3D printers) are apparently standardized for a 3-vertex chirality
> that is opposite to POV-ray's own triangle-rendering scheme.
Yes, our left-handed coordinate system can drive people crazy at times.
It's also why things are best coded to be adjustable.
If you put your triangle vertices into an array and referenced them by index,
then it's something that can be adjusted - and even used as data apart from the
mesh2 definition. Hard-coding the structure makes it inaccessible from SDL,
which has been a long-standing complaint in POV-Ray development.
Loading the data into an array makes it available to the user to post-process
after loading.
<-1, 0, 1> * 1 + 1 = array indices <0, 1, 2>
<-1, 0, 1> * -1 + 1 = array indices <2, 1, 0>
So everything is easily flipped with a simple pre-multiplier
It also allows mesh deformation (similar to what Josh English wanted to do)
because you have direct access to modify the data.
It also allows you to compute the normals differently.
Not saying that Sergei has to do it that way, but it definitely is something to
think about, and perhaps experiment with implementing in your own converter.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Yes, our left-handed coordinate system can drive people crazy at times.
>
Yeah, *that* topic probably needs a fresh-discussion thread of its own, just as
a 'refresher course.'
But as it impacts STL conversion: All of the STL files I've worked with recently
follow the 'right-hand rule'-- the +x direction faces LEFT rather than to the
right as in POV-ray. (Another 3D-printing standard, apparently.) So STL-to-mesh
conversions have to be mirror-flipped in x to render correctly for us. In my own
code, I simply scaled the final mesh by <-1,1,1>.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/10/2025 14:02, Bald Eagle wrote:
> Yes, our left-handed coordinate system can drive people crazy at times.
> It's also why things are best coded to be adjustable.
> ...
Thanks, Bill, using arrays is a very good idea, I will think about
details of implementation to make this feature useful and flexible,
then include in next release.
I can also imagine a set of switchable options to control desired
format, including orientation of coordinate system - any proposals are
are welcome.
Besides controlling the mesh itself, arrays will allow decoration by
additional elements, positioned at the vertices, achieving different
interesting effects, like on attached image.
--
YB
Post a reply to this message
Attachments:
Download 'beads.png' (160 KB)
Preview of image 'beads.png'
|
|
| |
| |
|
|
|
|
| |
|
|
