all2pov is an utility for povray that uses irrlicht, a free 3d engine 
wich is capable to load several different mesh file formats, to export 
models into povray sdl. It loads the model using irrlicht and then 
export it in a povray sdl .inc file. It exports 
vertices,indices,materials(textures,diffuse,ambient,specular,shininess) 
and uv coordinates into a mesh2 block. It full support mesh with 
multiple sub-meshes
Since it uses Irrlicht under NULL device you don't need directx nor 
opengl support at all.
Here you will find a list of irrlicht supported file formats: 
http://irrlicht.sourceforge.net/features.html#supportedformats
Add md3 to this list (still in beta but works very well)

no binary for the moment, only source code (GPLv2), documentation and 
examples in the svn server:

svn co https://aresfps.svn.sourceforge.net/svnroot/aresfps all2pov

online browsing works too

http://aresfps.svn.sourceforge.net/viewvc/aresfps/all2pov/

comments are very appreciated!!

Post a reply to this message

povray <nos### [at] nospamit> wrote:
> comments are very appreciated!!

  Some programmatical issues:

- You could increase portability by avoiding things like: system("pause");
(Besides, pausing after a syntax error is not customary in CLI apps. It
interferes with automatic processing, eg. when using makefiles.)

- There's a potential out-of-boundaries access in the GetOption() function:
You index param[0] and param[1] without checking that the string is long
enough for that.

- fprintf( pfile, data[i].c_str()); is not safe, if the string in question
happens to have any % symbols. (Unlikely, but can happen.) The proper way
of doing it is: fprintf( pfile, "%s", data[i].c_str());
  (You could also have used an fwrite() instead. Or C++ streams.)

- It would be more informative if you used perror() (or strerror()) when
opening a file fails. That way the user would get the exact reason for the
failure.

- In the GetExtention() function (which should really be name GetExtension)
does not check if finding the '.' character succeeded. If it fails, then
std::string::npos will be returned, which you assign to an int (rather
than size_t), which you then increment and given as parameter to
std::string::erase. The result is undefined (and might result in a crash).
You should use size_t rather than int, and check if std::string::npos was
returned.
  Likewise for SetExtention().

- argv[0] is in no way guaranteed to contain the path to the executable.
In fact, in most situations it won't contain it.


  I'm not going to nitpick about performance issues because they are
not urgently relevant (but might be an issue if you are converting huge
files).

-- 
                                                          - Warp

Post a reply to this message

Warp ha scritto:
> povray <nos### [at] nospamit> wrote:
>> comments are very appreciated!!

thanks a lot for the suggestions. i agree with all the points but i 
didn't understand the last. i was sure argv[0] contained the path to the 
current executable. What does you suggest to get the path to the current 
executable? is there a c standard function to do so?

all the changes committed to svn. still handle unix path and change int 
to the correct return type size_t for std::string::find() calls. option 
parser completely rewritten. now you need a space between option and the 
parameter ("all2pov -i input" and not "all2pov -i"input"" as was before)

Have you compiled the source?

Post a reply to this message

Raffaele <nos### [at] nospamit> wrote:
> i was sure argv[0] contained the path to the 
> current executable.

  Actually it's very rare for it to contain it.

> What does you suggest to get the path to the current 
> executable? is there a c standard function to do so?

  There's no standard C or C++ function to do that. I'm not even sure
there's a POSIX function to do that (although there might be, as POSIX
as tons of things). I'm not even sure the OS is in any way required to
keep/provide this information to the application.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Raffaele <nos### [at] nospamit> wrote:
> > i was sure argv[0] contained the path to the
> > current executable.
>
>   Actually it's very rare for it to contain it.
>
> > What does you suggest to get the path to the current
> > executable? is there a c standard function to do so?
>
>   There's no standard C or C++ function to do that. I'm not even sure
> there's a POSIX function to do that (although there might be, as POSIX
> as tons of things). I'm not even sure the OS is in any way required to
> keep/provide this information to the application.
>
> --
>                                                           - Warp

There are some ways you can still find it out.

Windows GetModuleFileName or something like that should return the path to the
executable file.  On Linux I think there is either an environment variable or
symbolic link, something like /proc/self or _SELF or something.  I've read
about it it's supposed to contain the path to the executable.  I don't think it
is a POSIX standard but just used on Linux.

User supplied by environment variables or command-line options.  If both are
used, a command-line option should probably take priority over the environment
variable.

Also a simple 'generic' auto detection can work reasonably well most of the time

If argv[0] is an absolute path, the use it.
If argv[0] is a relative path with path components, get the current working
directory and append argv[0].
If argv[0] is only a program name with no path components, on Windows use the
above method first.  On Linux and after the above on Windows search the PATH
environment variable and for each item append argv[0] to see if it is found.

boost::filesystem may have something that already solves this

Post a reply to this message

Allen wrote:

> There are some ways you can still find it out.
> 
> Windows GetModuleFileName or something like that should return the path to
> the
> executable file.  On Linux I think there is either an environment variable
> or
> symbolic link, something like /proc/self or _SELF or something.  I've read
> about it it's supposed to contain the path to the executable.  I don't
> think it is a POSIX standard but just used on Linux.

On Linux, /proc/self/exe is a symbolic link to the executable.

-a.

Post a reply to this message