 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I usually use Pose-Ray (of course) for things like this,
but I was wondering if any of the linux users have any other tools for taking
obj, stl, or other mesh files and converting that to a file easily used in
POV-Ray.
I found this, which seems to have been dropped for the moment...
https://github.com/monkstone/povmesh
Just as an interesting aside:
If anyone understands the file structures well enough, it would be rather
interesting to do the conversion completely in SDL, especially if the output
format were mesh2 - since it would provide a framework for showing how to do
that. It would sort of be its own tutorial. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscape net> wrote:
> I usually use Pose-Ray (of course) for things like this,
you can run that on a Linux box?
> but I was wondering if any of the linux users have any other tools for taking
> obj, stl, or other mesh files and converting that to a file easily used in
> POV-Ray.
>
> I found this, which seems to have been dropped for the moment...
> https://github.com/monkstone/povmesh
had not known of this either.
self prefers small, dedicated tools. the source linked ('gts2pov'[*]) builds a
small and reasonably quick executable, used for these:
<http://news.povray.org/povray.text.scene-files/thread/%3Cweb.5e1881adbbdf84bb8c662f470%40news.povray.org%3E/>
to compile:
$ cc -std=c99 -pedantic -Wall -Wextra -O2 -fPIC -o gts2pov gte2pov.c
edit line 40 to raise the maximum vertices per mesh, default 1M.
[*] <https://drive.google.com/open?id=14Luh5u-39MWQzo8NSbTldAH2MUMNXC5T>
> Just as an interesting aside:
> If anyone understands the file structures well enough, it would be rather
> interesting to do the conversion completely in SDL,
that does sound, um, a little masochistic. :-)
> especially if the output
> format were mesh2 - since it would provide a framework for showing how to do
> that. It would sort of be its own tutorial. :)
the user ought to have choice of 'mesh' or 'mesh2', imo.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 22/01/2020 à 21:57, Bald Eagle a écrit :
>
>
> I usually use Pose-Ray (of course) for things like this,
>
> but I was wondering if any of the linux users have any other tools for taking
> obj, stl, or other mesh files and converting that to a file easily used in
> POV-Ray.
>
> I found this, which seems to have been dropped for the moment...
> https://github.com/monkstone/povmesh
>
> Just as an interesting aside:
> If anyone understands the file structures well enough, it would be rather
> interesting to do the conversion completely in SDL, especially if the output
> format were mesh2 - since it would provide a framework for showing how to do
> that. It would sort of be its own tutorial. :)
>
>
I made a custom extension to import & export STL (as well as GTS).
As SDL is only able to handle text (and not binary file), it was not an
option.
Problem with STL: there is 2 opposite specifications for colour, so I
just dropped that part too, only load & save the shape.
OBJ specification is text, but not made only of triangle (you can have 4
points faces).
I also made an extension to be able to read back the data of a mesh, it
could be used to save it as mesh2 (but really, STL is faster if you can
cope with the constraint of being in the positive corner cube)
Whatever, I use *meshlab* to convert between these formats (and perform
also other operations, including preview).
Also, *makehuman* is a nice way to get mesh of human bodies if you
intend to have a set of Greek statues.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] freefr> wrote:
> I made a custom extension to import & export STL (as well as GTS).
> As SDL is only able to handle text (and not binary file), it was not an
> option.
I saw some search results regarding hgpovray38, but I didn't really "get" it.
Don't we have the ability to read/write binary files in SDL?
I was searching for a way to write GrADS data, and finally reminded myself that
it was possible.
http://wiki.povray.org/content/Reference:File_I/O_Directives
uint8 - unsigned byte (0..255)
sint8 - signed byte (-128..127)
uint16be, uint16le - unsigned 16-bit word (0..65535)
sint16be, sint16le - signed 16-bit word (-32768..32767)
sint32be, sint32le - signed 32-bit word (-2^31..2^31-1)
> Problem with STL: there is 2 opposite specifications for colour, so I
> just dropped that part too, only load & save the shape.
>
> OBJ specification is text, but not made only of triangle (you can have 4
> points faces).
Well that's "easy enough" to grapple with - just use corners 1, 2 & 3, and 3, 4,
& 1 to make 2 separate triangles.
> I also made an extension to be able to read back the data of a mesh, it
> could be used to save it as mesh2 (but really, STL is faster if you can
> cope with the constraint of being in the positive corner cube)
Huh.
I got the impression from the documentation that mesh2 was "better" - so why is
STL faster?
I'm impressed that you coded something up for mesh2 - I was mulling over how to
do that, and it seemed like a lot of record-keeping to know which triangles
were which and what ones shared vertices....
> Whatever, I use *meshlab* to convert between these formats (and perform
> also other operations, including preview).
Yes, I think I stumbled across a link to meshlab. I'll try to install that some
time soon, as it a nice program for viewing and fixing meshes.
> Also, *makehuman* is a nice way to get mesh of human bodies if you
> intend to have a set of Greek statues.
Hmmm. IIRC that project was abandoned some time ago - I'll look and see if I
can find the files for that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > I usually use Pose-Ray (of course) for things like this,
>
> you can run that on a Linux box?
Not that I'm aware. It's what I used when I ran Windows.
regarding gts, it seems like Melody might like the Puget Sound and Grand Canyon
models to complement his cool Hawaiian islands animations. :)
https://www.cc.gatech.edu/projects/large_models/
> > Just as an interesting aside:
> > If anyone understands the file structures well enough, it would be rather
> > interesting to do the conversion completely in SDL,
>
> that does sound, um, a little masochistic. :-)
I opened STL in text editor, and it's just an issue of syntax.
SDL well and truly sucks for manipulating text, however I wrote a LibreOffice
spreadsheet last night in no time that converts STL to POV-Ray mesh {} format.
Looks like it ought to be just as simple to write something in C, C++, or as a
shell script.
I might continue with my initial efforts in SDL just because it will likely
yield some useful text-handling macros.
STL looks to be just:
solid Mesh
facet normal -0.296431 -0.955054 -0.000000
outer loop
vertex -67.932732 36.474884 24.903671
vertex -82.486053 40.991966 22.546505
vertex -67.932732 36.474884 20.042015
endloop
endfacet
... repeat ...
endsolid Mesh
So I just started with "mesh{", ignored the loop lines, commented out the
normal, consolidated the "vertex" lines into "triangle {<1>, <2>, <3>}", and
closed it with "}"
Done.
[FYI - triangle{} did not like a trailing extra comma after the 3rd vertex]
With regard to the #read directive:
"Undefined identifiers will be turned into global identifiers of the type
determined by the data which is read. Previously defined identifiers remain at
whatever global/local status they had when originally created. Type checking is
performed to insure that the proper type data is read into these identifiers."
It would be SO NICE to have an end-user function in SDL for type-checking data.
> the user ought to have choice of 'mesh' or 'mesh2', imo.
Agreed, but mesh is trivial - my point was only that mesh2 seems to be so
challenging that seeing how to go about coding it would be a valuable tutorial.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> regarding gts, it seems like Melody might like the Puget Sound and Grand Canyon
> models to complement his cool Hawaiian islands animations. :)
> https://www.cc.gatech.edu/projects/large_models/
nope, I don't see GTS data there. :-(
> > > Just as an interesting aside:
> > > If anyone understands the file structures well enough, it would be rather
> > > interesting to do the conversion completely in SDL,
> > that does sound, um, a little masochistic. :-)
>
> I opened STL in text editor, and it's just an issue of syntax.
> SDL well and truly sucks for manipulating text, however I wrote a LibreOffice
> spreadsheet last night in no time that converts STL to POV-Ray mesh {} format.
> Looks like it ought to be just as simple to write something in C, C++, or as a
> shell script.
the STL file format is from 1987, according to Wikipedia, so you'd think that
somebody already wrote such an utility (in those 30-odd years).
> ...
> With regard to the #read directive:
> "Undefined identifiers will be turned into global identifiers of the type
> determined by the data which is read. Previously defined identifiers remain at
> whatever global/local status they had when originally created. Type checking is
> performed to insure that the proper type data is read into these identifiers."
>
> It would be SO NICE to have an end-user function in SDL for type-checking data.
agree, POV-Ray would benefit from having more (any! :-)) "introspection" tools.
> > the user ought to have choice of 'mesh' or 'mesh2', imo.
>
> Agreed, but mesh is trivial - my point was only that mesh2 seems to be so
> challenging that seeing how to go about coding it would be a valuable tutorial.
v little difference for GTS data, may be different for other format(s).
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 24/01/2020 à 19:27, Bald Eagle a écrit :
>
> Le_Forgeron <jgr### [at] freefr> wrote:
>
>> I made a custom extension to import & export STL (as well as GTS).
>> As SDL is only able to handle text (and not binary file), it was not an
>> option.
>
> I saw some search results regarding hgpovray38, but I didn't really "get" it.
> Don't we have the ability to read/write binary files in SDL?
> I was searching for a way to write GrADS data, and finally reminded myself that
> it was possible.
> http://wiki.povray.org/content/Reference:File_I/O_Directives
> uint8 - unsigned byte (0..255)
> sint8 - signed byte (-128..127)
> uint16be, uint16le - unsigned 16-bit word (0..65535)
> sint16be, sint16le - signed 16-bit word (-32768..32767)
> sint32be, sint32le - signed 32-bit word (-2^31..2^31-1)
>
Writing: yes. But reading ?
>> Problem with STL: there is 2 opposite specifications for colour, so I
>> just dropped that part too, only load & save the shape.
>>
>> OBJ specification is text, but not made only of triangle (you can have 4
>> points faces).
>
> Well that's "easy enough" to grapple with - just use corners 1, 2 & 3, and 3, 4,
> & 1 to make 2 separate triangles.
I write code that I need, usually (I once wrote Nurbs support, only to
get no modeler at the end that would export raw nurbs data). I did not
need Obj support, whereas I was in need of STL (due to converting povray
object into real 3D printed object) and GTS (because the rabbit is so
lovely and the GTS collection was interesting).
Feel free to play with Obj if you need:
https://en.wikipedia.org/wiki/Wavefront_.obj_file
I was wrong above, a face has a minimum of 3 points, but no upper limit,
and you can encounter other elements (full spec in
http://www.martinreddy.net/gfx/3d/OBJ.spec )
>
>> I also made an extension to be able to read back the data of a mesh, it
>> could be used to save it as mesh2 (but really, STL is faster if you can
>> cope with the constraint of being in the positive corner cube)
>
> Huh.
> I got the impression from the documentation that mesh2 was "better" - so why is
> STL faster?
Ok, it depends on the number of points.
On reading:
Mesh2 is filled directly in pov structure, but each number need to be
parsed from its text form to binary.
STL is binary, so no parsing time, but the structure in memory need to
be searched as it grows to provide an efficient set of data for povray.
On writing: the speed is probably about the same.
> I'm impressed that you coded something up for mesh2 - I was mulling over how to
> do that, and it seemed like a lot of record-keeping to know which triangles
> were which and what ones shared vertices....
>
Mesh2 is an external representation of the internal "mesh" structure. It
is as raw as possible. Mesh is more natural description for the same
data, but it is slower to parse (the same way STL is) because additional
computations and searches must be performed to get into the "mesh"
structure.
>> Whatever, I use *meshlab* to convert between these formats (and perform
>> also other operations, including preview).
>
> Yes, I think I stumbled across a link to meshlab. I'll try to install that some
> time soon, as it a nice program for viewing and fixing meshes.
>
>> Also, *makehuman* is a nice way to get mesh of human bodies if you
>> intend to have a set of Greek statues.
>
> Hmmm. IIRC that project was abandoned some time ago - I'll look and see if I
> can find the files for that.
>
>
>
Please check http://www.makehumancommunity.org/
Seems still alive, as 1.2.0 alpha4 was announced on 16th December 2019.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> I usually use Pose-Ray (of course) for things like this,
>
> but I was wondering if any of the linux users have any other tools for taking
> obj, stl, or other mesh files and converting that to a file easily used in
> POV-Ray.
>
> I found this, which seems to have been dropped for the moment...
> https://github.com/monkstone/povmesh
>
> Just as an interesting aside:
> If anyone understands the file structures well enough, it would be rather
> interesting to do the conversion completely in SDL, especially if the output
> format were mesh2 - since it would provide a framework for showing how to do
> that. It would sort of be its own tutorial. :)
Blender
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
