Okay, here's what I have so far.  I changed the macro around so that it
handles all of the mesh2 data exported from Wings3d.  Added normal_indices,
uv_vectors and uv_indices.  It was fairly easy though concidering that I
just reused your code with different variables.

I also added two parameters to the macro: file_01 and file_02.  With these
you pass strings containing the name of the variables used for your data
arrays.  It probably could have been done more easily, but at least my
soulution was entertaining.

I also finished a Python script to convert a mesh2 object into a mesh2
interpolatable file.  The program is very clumsy, it could be cleaner,
faster, use more modular design... But it works!  Well sort of ~_~
While I was writing it I was using your examples, and some meshes I had
laying around as examples.  Well all the files I have seen have had each
peice of data on it's own line but it turns out that output from AOI has
each vector on a seperate line.  So the program works on Wings3d meshes, but
not with AOI and probably not with other programs output either.  Oh well it
shouldn't be too hard to fix.

You can mess with the files as much as you want, I think there might be a
problem with the variable name passing if you want to have a look at it.
Also I still think that the mesh can be converted in SDL, I'm just not
clever enough at the moment to say how.  hope this was useful!

Post a reply to this message

Attachments:
Download 'mesh2.py.txt' (8 KB) Download 'Interpolate_Mesh2.inc.txt' (5 KB)

Oh!  I forgot to say that I didn't set this up to exicute under linux
either, so if you use the penguin you'll need to type out:

python /mesh2.py

but other then that it should work, even on the commandline!... Well only on
the commandline, but Ill make a GUI when its finished.

Post a reply to this message

> I also finished a Python script
I don't have Python so I can't run the script. But I think, it wouldn't be
too overwhelming to modify the exporter in Wings3D. We have the source code
available. I don't know the langauge, but it can't be too hard to remove the
redundant code so the plugin ONLY output's the raw data. This makes a direct
connection possible between Wings and POV, at least.

> Also I still think that the mesh can be converted in SDL
If the mesh2 file doesn't have any double-quotes ( " ) it might be possible
to do a trick: Have POV-Ray modify the entire file by wrapping  "  signs
around it. Then the file would be treated as a one large string, when read
by the #read directive. But maybe the string would be too large? It's the
only way, but a clumsy method in any case.

It would be better to convince the POV-Team to try a new command in POV -
just in my humble opinion! I've discussed it briefly with the C++ people in
charge in the last 3 days but without luck. You might consider contributing
with your thoughts. I consider this as a general limitation with POV, as it
can never read files from other software.

> hope this was useful!

Yes, thank you.
Hugo

Post a reply to this message

Hugo Asm wrote:
>> I also finished a Python script
>I don't have Python so I can't run the script. But I think, it wouldn't be
>too overwhelming to modify the exporter in Wings3D. We have the source code
>available. I don't know the langauge, but it can't be too hard to remove the
>redundant code so the plugin ONLY output's the raw data. This makes a direct
>connection possible between Wings and POV, at least.
>
>> Also I still think that the mesh can be converted in SDL
>If the mesh2 file doesn't have any double-quotes ( " ) it might be possible
>to do a trick: Have POV-Ray modify the entire file by wrapping  "  signs
>around it. Then the file would be treated as a one large string, when read
>by the #read directive. But maybe the string would be too large? It's the
>only way, but a clumsy method in any case.
>
>It would be better to convince the POV-Team to try a new command in POV -
>just in my humble opinion! I've discussed it briefly with the C++ people in
>charge in the last 3 days but without luck. You might consider contributing
>with your thoughts. I consider this as a general limitation with POV, as it
>can never read files from other software.
>
>> hope this was useful!
>
>Yes, thank you.
>Hugo
>

I thought of something this morning, I got the macro to include all mesh2
data Except textures the texture assignment data in the face_indices.  My
first thought was to simply save the whole face_indices statement as a
string, and paste it into new mesh2 at the end of the macro.  But it needs
to be data, so you would need a way to break the string on commas.  Maybe
the macro can take the string, output it to a temp file, and then read the
data back into itself?

It would be nice if Povray could handle more file reading commands, like
keeping track of where you are in a file, reading lines etc.  Also one or
two more string handling commands.  I think the problem with reading and
writing an arbitrary file used to be the risk of messing up the files on
someone elses computer.  Now though there are built-in script restrictions
which guard against virii or other mallicious code.

It shouldnt be too hard to write in some additional file handling code, as
you would probably just give Povray access to the c library code for
handling files.  Since this would be an advanced feauture you could leave
the syntax fairly close to the origional C equivalent.  Unfortunatly as far
as I have seen the only way to get new commands into Povray is to write a
patch, which then goes into Megapov if it is useful, and then finaly gets
included in the next version of the official engine.

I should be able to "compile" my python code into an executable that can be
run on windows.  I haven't tested out the method for doing this though, and
I don't know how high the file size will grow.  Plus people are rightly
leery of downloading and running strange exicutables.  Raw source code is
smaller, less scary, and more portable then exe, so I tried that first.  I
think I will wait until I have all the bugs worked out to release a exe
though.

Man I need to get a signature...

Post a reply to this message

I like your thoughts and I hope you will share them with the MegaPOV team.
They might not read this post.

As you, I prefer a direct connection between modellers and POV-Ray. Any
stand-alone program that acts as converter, isn't the best solution.
Currently mesh2 files are out of reach for a macro that tries to work on the
data. The core of this problem is the mesh2 format; not the #read directive.
But instead of adding a mesh3 format, I think POV-Ray could benefit in
general from better reading capabilities.

Other programs usually have a long list of supported formats, to export and
import. Why not POV-Ray? Yes, it's a different approch to 3D and more math
minded. But why stand in the corner, when combining talents from other
software, would help POV-Ray to rock even more. There is a risk that people
would begin to use POV merely as a raytracer; thereby it would loose some of
it's uniqueness. But still...!

Regards,
Hugo

Post a reply to this message

On Sun, 11 May 2003 18:41:33 +0200, "Hugo Asm" <hua### [at] post3teledk> wrote:
> Other programs usually have a long list of supported formats, to export and
> import. Why not POV-Ray?

The 'parse.cpp' file is already the largest file in POV-Ray which simple means
there is the largest amount of work included there (and it is one of several
files which are responsible for parsing). Writing parser for other formats would
require similiar large amount of work. It is not just opening file and reading
from it. You have call creation methods for each object, fill all fields,
precompute some coefficients, operate on some defaults. Give me a free
unemployed programmer and I will do import{} feature in a week ;-)
Otherwise converters do nice job and can be probably easy automated with
pre_scene_command.

ABX

Post a reply to this message

On Sun, 11 May 2003 17:37:10 +0200, "Hugo Asm" <hua### [at] post3teledk> wrote:
> It would be better to convince the POV-Team to try a new command in POV -
> just in my humble opinion!

I'm not a POV-Team member but have you noticed that even if POV-Team would
decide to follow your suggestion, you will not receive new feature within two or
more years ? At least I do not expect POV-Ray 4.0 earlier.

> I've discussed it briefly with the C++ people in
> charge in the last 3 days but without luck.

With luck. I decided to look into sources what can be done for you purposes but
this still does not mean that you will receive any patch earlier than within
month. I still do not think your idea is good. I would rather look into more
general solution which also solves your case. Perhaps access of internal mesh
data would be better...

> I consider this as a general limitation with POV, as it
> can never read files from other software.

This is a philosophy question, probably. Is POV created to compensate laziness
of users of using external converters (including handmade scripts)? Is only
small group responsible of extending POV capabilities ? POV-Ray is a free
application made in free time. Do not expect from it to be everything.

ABX

Post a reply to this message

On Mon, 12 May 2003 10:17:06 +0200, "Hugo Asm" <hua### [at] post3teledk> wrote:
> > I'm not a POV-Team member
>
> Yes. I should have written "MegaPOV team".

The problems adressed to MegaPOV team should be discussed in
povray.unofficial.patches as stated in introduction to MegaPOV 1.0 manual :-)

ABX

Post a reply to this message

> The problems adressed to MegaPOV team should be discussed in
> povray.unofficial.patches as stated in introduction to MegaPOV 1.0
> manual :-)

Good grief I need to do my homework!
I just moved my reply to advanced-users.. Is that good or bad?

Post a reply to this message

Hugo Asm wrote:
>> The problems adressed to MegaPOV team should be discussed in
>> povray.unofficial.patches as stated in introduction to MegaPOV 1.0
>> manual :-)
>
>Good grief I need to do my homework!
>I just moved my reply to advanced-users.. Is that good or bad?
>
 I have no idea anymore, I think I will stick to images animations and
scenefiles, let the programmers take care of their own buisness.

ABX thankyou for all your comments!  I am honored to have you take interest
in this small issue.  I understand why you would not wish to add more work
to the parse.cpp file.  I would not ask this of you, I would instead
preffer that we who use the SDL be given more versitile methods for reading
in arbitrary data files.  No parsing need be done by the povray engine,
just increased access to stdio.h file read write abilities. a direct
pipeline from the strings returned by fgetc, fgets, etc to the user.  surely
passing strings back and forth between C and Povray can't be too difficult?

I don't think you should bother with this though, I think I will try to
setup some extended read/write for Povray, and then send you a patch.  If it
is good you could include it in MegaPov, and either way I will have the
functionality I need.  I'll hate to have to mess around in C++ though, I
have never like C...

Post a reply to this message