"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > ...
> > The recognizability at first sight of each mesh object.
> > It will take a little time because I want to align on a new feature all my
> > plugins and also the executable that I use for the conversions (CAD - STL
> > -PovRay) of my models.
> > Let me explain better.
> > The various formats "understand" which mesh they are translating because the
> > finishes are defined in a common and recognizable format that begins with the
> > CAD drawing that assigns the layer name.
> > In the layer name there is the color information.
> > The name is in hexadecimal, because it is easy to read.
>
> :-)
>
>
> > Example HEXFF0000T7F means rgb red, with alpha (Transparency) equal to 50%, 127
> > of 255
> > This system creates a database with its pointers to finishes that helps organize
> > the meshes and the smooth.
> > UDT  for my system details for a model:
> > ...
> >  LayerCo As Double    ' 8 bytes
> >  EntitCo As Double    ' 8 bytes
>
> "Co" as in colour, I assume ?
>
>
> >  Transp  As Double    ' 8 bytes
> > ...
> > END OF FILE
> >
> >  TargetX AS DOUBLE
> >  TargetY AS DOUBLE
> >  TargetZ AS DOUBLE
> >  WPntX   AS DOUBLE 'view = 48 bytes
> >  WPntY   AS DOUBLE
> >  WPntZ   AS DOUBLE
> >  Orto    AS DOUBLE   '8 bytes
> >
>
> what are those for ?
>
>
> > But it's a database that uses long integers (or long ) and I can't add strings
> > for various reasons.
>
> exporting to some "common" ASCII format, eg CSV, and importing such formats, is
> ime (much) easier than "faffing about" with binary file formats.
>
> is there a reason you don't use (integer) keys to tie together the bits of data?
Yes, Co is color, the CAD can have two colors, a parent for the layer, and one
for the object. If there is no child color, the parent is assumed.
Sketchup does the same thing with groups or istances.
By the Pointers are integers.
Only data must be float
When I load the contents of the various formats of files I use a memory stream ,
it does not need to be written to file
The UDT blocks are a fast and easy way (with arrays) to upload any type of file,
step by step in the memory stream.
It is now a proven system that acts as an interpreter between formats.
Even the reordering and grouping operations are immediate.
When I will implement the dictionary for strings it will be immediate, because
the pointers can to be the same in the second memorysteam.
Why should I depend on systems to adapt? Exactly like when I have to extract for
example only the 3 vertices, where I aim to read the block the triplet of xyz
with their specific UDT that loads the vertices. And I can also print it as a
memory dump when I have to debug. It is now a proven system, I have not explored
the memory limits, I do not need to declare limits in a memorystream, never had
problems even with huge objects. The only problems sometimes arise with the STLs
that have a limit that I do not remember, but it is big...
In other words, a 96 byte jump, and I'm ready to read the new face.
I'm also easily implementing recursive loops.
However, the dictionary could go along with it, the strings are fast to read if
they are fixed length. To align the mesh database I could reserve 6 strings of
16 characters for each element,
which is a lot of information...

Post a reply to this message