POV-Ray : Newsgroups : povray.unofficial.patches : yuqk feature requests / suggestions : Re: yuqk feature requests / suggestions Server Time
21 Apr 2024 07:00:41 EDT (-0400)
  Re: yuqk feature requests / suggestions  
From: Le Forgeron
Date: 15 Dec 2023 13:40:05
Message: <657c9d85@news.povray.org>
Le 14/11/2023 à 20:36, Bald Eagle a écrit :
 > William F Pokorny <ano### [at] anonymousorg> wrote:
 >> - My direction with yuqk is generally away from larger extensions like
 >> this being jammed into the POV-Ray core code. They make for a mess as
 >> seen by the user and those supporting / changing the internal code.
 > Sorry, my Man, but I must respectfully disagree.
 > I'm not talking about binary STL, I'm talking about ASCII STL, or "STLA"
 > https://paulbourke.net/dataformats/stl/

You can always use a converter for STL from Ascii to Binary, it will be 
far simpler than having yet another extension of the parser, or even a 
dedicated parser. It's only once you have experimented handling the 
versatility of text input that you start to like strict binary encoding.

 > It's a sparrow's fart away from being a legit POV-Ray mesh {} 
definition, which
 > is why I said it would be _trivial_ to implement.
 > Copy mesh{} code, paste mesh {} code, edit mesh {} code.   Done.
 > Just rather than mesh {}, call it stl {}.

Somebody seems enthusiast about mesh... you have probably no idea yet of 
the nest of snakes you are to discover.

mesh{} and mesh2{} are two syntax for the same final data structure, but 
the latter is far faster to parse when the number of points starts 
increasing, as the computation are in mesh2{}, whereas mesh{} just do it 
on the fly for you.

 > We can find faster, more versatile and agile ways to do things, and 
open up the
 > code base to further expansion by making the addition of code modules 
easier to
 > implement.

Never forget portability & universality. Povray could run on Amiga.

Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.