For my last version see zip file.

I had hoped a bit for a nice collection of cars and people.
It looks nice, but I'm sure I've done too much work for 3 vehicles and 2 people.
Maybe I'll continue and clean up better, should new models appear.

Ciao
Ma

Post a reply to this message

Attachments:
Download 'gio_250624.zip' (718 KB)

Here an image will all models

ma

Post a reply to this message

Attachments:
Download 'test_all_01.png' (807 KB)

Preview of image 'test_all_01.png'

"Maetes" <nomail@nomail> wrote:
> Here an image will all models
>
> ma

very nice!

I'm preparing some high definition models, but in the meantime, to be observed
from afar because it's very light, a driver (or a G-man) lol is needed to
monitor the vehicles....
It's a inc, remove the two bottom bars to use it as a standalone pov..
B.R.
G.

Post a reply to this message

Attachments:
Download 'maninblack.zip' (68 KB)

hi,

"GioSeregni" <gms### [at] hotmailcom> wrote:
> "Maetes" <nomail@nomail> wrote:
> > Here an image will all models
> > ma
> very nice!
>
> I'm preparing some high definition models, but in the meantime, to be observed
> from afar because it's very light, a driver (or a G-man) lol is needed to
> monitor the vehicles....
> It's a inc, remove the two bottom bars to use it as a standalone pov..

thank you !  if, while you're on the exporting things stuff, you could output
the finish with a braced reflection[*], written eg:
  finish{ambient .21 diffuse .78 reflection {.01}}
then your code will be correct, and can be used with WFP's 'yuqk' branch/fork.

[*] as documented
<wiki.povray.org/content/Reference:Finish#Specular_Reflection>.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > "Maetes" <nomail@nomail> wrote:
> > > Here an image will all models
> > > ma
> > very nice!
> >
> > I'm preparing some high definition models, but in the meantime, to be observed
> > from afar because it's very light, a driver (or a G-man) lol is needed to
> > monitor the vehicles....
> > It's a inc, remove the two bottom bars to use it as a standalone pov..
>
> thank you !  if, while you're on the exporting things stuff, you could output
> the finish with a braced reflection[*], written eg:
>   finish{ambient .21 diffuse .78 reflection {.01}}
> then your code will be correct, and can be used with WFP's 'yuqk' branch/fork.
>
> [*] as documented
> <wiki.povray.org/content/Reference:Finish#Specular_Reflection>.
>
>
> regards, jr.

I have to apologize because my English is poor and I don't understand the
problem.
Each mesh represents an object that is part of the complete shape, but has its
autonomy, each mesh has its definition of RGB or RGB color with alpha
transparency. The rest of the definition is standard, and can be modified as you
want.
My standard definition does not give me any errors or warnings by Povray, so it
is correct.
It is also easy to modify it, just search on Povray for the keywords -end mesh-
of the comments and modify the previous lines.
The definition is double with the inside because experimenting I saw that this
system hides a bit the artifacts of the smooth_triangle bug. Let's hope they are
solved with the next version of Povray ...
.... please
" WFP's 'yuqk' branch/fork." sorry , what is the meaning? I cannot understand ..
because I don't know these abbreviations

Sorry againg and many thanks ...
BR
G.

Post a reply to this message

hi,

"GioSeregni" <gms### [at] hotmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > ...hi,
> > thank you !  if, while you're on the exporting things stuff, you could output
> > the finish with a braced reflection[*], written eg:
> >   finish{ambient .21 diffuse .78 reflection {.01}}
> > then your code will be correct, and can be used with WFP's 'yuqk' branch/fork.
> > [*] as documented
> > <wiki.povray.org/content/Reference:Finish#Specular_Reflection>.
>
> I have to apologize because my English is poor and I don't understand the
> problem.

nessun problema.  (Google Translate tells me :-))


> ...
> My standard definition does not give me any errors or warnings by Povray, so it
> is correct.

no, alas.  no warnings/errors is the result of (what I consider) bugs in the
POV-Ray parser.  see this example from the reference page:

    finish { reflection {1.0} ambient 0 diffuse 0 }

your code is missing the braces required by 'reflection'.


> ...
> " WFP's 'yuqk' branch/fork." sorry , what is the meaning? I cannot understand ..
> because I don't know these abbreviations

yes, sorry.  WFP = William F Pokorny, he's the author of 'yuqk', a branch/fork
from the POV-Ray 3.8 line.  see, for example, the following thread:
<news.povray.org/povray.binaries.programming/thread/%3C68258118%241%40news.povray.org%3E/>

(and his parser is stricter than POV-Ray's, enforcing the 'reflection {}'
syntax)



regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > ...hi,
> > > thank you !  if, while you're on the exporting things stuff, you could output
> > > the finish with a braced reflection[*], written eg:
> > >   finish{ambient .21 diffuse .78 reflection {.01}}
> > > then your code will be correct, and can be used with WFP's 'yuqk' branch/fork.
> > > [*] as documented
> > > <wiki.povray.org/content/Reference:Finish#Specular_Reflection>.
> >
> > I have to apologize because my English is poor and I don't understand the
> > problem.
>
> nessun problema.  (Google Translate tells me :-))
>
>
> > ...
> > My standard definition does not give me any errors or warnings by Povray, so it
> > is correct.
>
> no, alas.  no warnings/errors is the result of (what I consider) bugs in the
> POV-Ray parser.  see this example from the reference page:
>
>     finish { reflection {1.0} ambient 0 diffuse 0 }
>
> your code is missing the braces required by 'reflection'.
>
>
> > ...
> > " WFP's 'yuqk' branch/fork." sorry , what is the meaning? I cannot understand ..
> > because I don't know these abbreviations
>
> yes, sorry.  WFP = William F Pokorny, he's the author of 'yuqk', a branch/fork
> from the POV-Ray 3.8 line.  see, for example, the following thread:
>
<news.povray.org/povray.binaries.programming/thread/%3C68258118%241%40news.povray.org%3E/>
>
> (and his parser is stricter than POV-Ray's, enforcing the 'reflection {}'
> syntax)
>
>
>
> regards, jr.

Thanks, great, now I understand and I corrected the finish code.
It was simple and quick, but now I have to take a short break to fix an issue
that seems important to me.
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:

TYPE Internal
 numfacets AS LONG ' 4 bytes
 Xmin AS DOUBLE
 Xmax AS DOUBLE
 Ymin AS DOUBLE
 Ymax AS DOUBLE
 Zmin AS DOUBLE
 Zmax AS DOUBLE    'END HEADER

' start bloCnt________________________ LOOP

 x0      As Double
 y0      AS Double
 z0      As Double
 x1      As Double
 y1      As Double 'vertex = 72 bytes
 z1      As Double
 x2      As Double
 y2      As Double
 z2      As Double '__________________
 LayerCo As Double    ' 8 bytes
 EntitCo As Double    ' 8 bytes
 Transp  As Double    ' 8 bytes
' end bloCnt  ________________________

'                   repeat bloCnts IN LOOP

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


But it's a database that uses long integers (or long ) and I can't add strings
for various reasons.
So I thought of a dictionary that uses the color as an index, to remember what
kind of object it is. A parallel, textual file of specifications.
Example "shoes"
In the database HEX000000
[T00] optional, not needed here.
But in the dictionary "clean and shiny shoes".
THIS COMMENT will be in a comment label in the PovRay mesh.
It will be useful to easily customize the files.
Not only that, this reminder label, adjustable in "human" language could be used
by those who want ALSO as a prompt for the AI... which could automatically
suggest the best finish for the mesh.
It may all seem very strange, but in this way each model, with a simple label at
the end of each mesh, becomes very flexible and improvable.

Thanks aagain! see you later ...
G.

Post a reply to this message

hi,

"GioSeregni" <gms### [at] hotmailcom> wrote:
> ...
> Thanks aagain! see you later ...

great, thank you.  looking forward to playing with the "next toy" :-).


regards, jr.

Post a reply to this message

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
?


> So I thought of a dictionary that uses the color as an index, to remember what
> kind of object it is. A parallel, textual file of specifications.
> Example "shoes"
> In the database HEX000000
> [T00] optional, not needed here.
> But in the dictionary "clean and shiny shoes".
> THIS COMMENT will be in a comment label in the PovRay mesh.
> It will be useful to easily customize the files.
> Not only that, this reminder label, adjustable in "human" language could be used
> by those who want ALSO as a prompt for the AI... which could automatically
> suggest the best finish for the mesh.
> It may all seem very strange, but in this way each model, with a simple label at
> the end of each mesh, becomes very flexible and improvable.

I'd have many more questions now, but will pass, for now.  agree that making
stuff human-readable is a good (the best ? :-)) way to go.


regards, jr.

Post a reply to this message

"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