> In converter, mentioned above, I solved this problem with Three.js.
> The following formats are supported now:
> Input: obj, fbx, glb, gltf, stl.
> Output: glb, gltf, pov.
> --
> YB

eh eh the output is never a problem
but I don't see the input for pov...
aand DXF very useful

I'm converting my converter from 32 to 64 bit. I started it many years ago,
using RapidQ (32) , easy to write but now too much slow.

So I looked for other languages, but gave up. Too many inclusions, too many
libraries to load even just to write "hello world."
It's not possible to always check for updates and compatibility, with algorithms
you have no way of controlling or to waste your time searching the bugs..
I finally arrived at a procedure that satisfies me.

For now I have kept the interface and file management written in Rapidq.
Instead the calls to the working and writing routines are entrusted to a second
executable written in QB64PE, which is great and compiles in C++.
Complicated comparison operations that used to take hours, such as those with
normal vectors on huge files, now take minutes.
And the others a few seconds.
I think that in a few months, I haven't written the documentation yet, I will be
able to make the two sources public.
Plus an include "lang".
Only 3 files, which can be compiled simply with the standard RapidQ and QB64PE
compilers, WITHOUT any additional libraries or anything else.

It's the only way to publish, today any executable file, if it doesn't have the
blackmail price for certification, it gives false positives.

BR
G.

Post a reply to this message